O que devo fazer quando 'svn cleanup' falhar?

Tenho muitas alterações em uma pasta de trabalho e algo estragou tudo ao tentar fazer uma atualização.

Agora, quando emito uma 'limpeza svn', recebo:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp é um novo arquivo que outro desenvolvedor adicionou e foi derrubado na atualização. Não existia na minha pasta de trabalho antes.

Existe algo que eu possa fazer para tentar avançar sem precisar fazer check-out de uma nova cópia do repositório?

Esclarecimento: Obrigado pelas sugestões sobre como mudar o diretório e trazer uma nova cópia para baixo. Eu sei que é uma opção, mas é uma que eu gostaria de evitar, pois há muitas alterações aninhadas em vários diretórios (isso deveria ter sido um ramo ...)

Estou esperando uma maneira mais agressiva de fazer a limpeza, talvez de alguma forma forçar o arquivo SVN está tendo problemas para voltar a um estado conhecido (e tentei excluir a cópia de trabalho dele ... isso não ajudou).

Quando começar tudo de novo, não é uma opção ...

Excluí o arquivo de log no .svndiretório (também excluí o arquivo incorreto .svn/props-base), fiz uma limpeza e retomei minha atualização.

As coisas mudaram com o SVN 1.7, e a solução popular de excluir o arquivo de log no diretório .svn não é viável com a mudança para uma implementação de cópia de trabalho de banco de dados.

Aqui está o que eu fiz que parecia funcionar:

1. Exclua o diretório .svn da sua cópia de trabalho.
2. Inicie um novo checkout em um novo diretório temporário.
3. Cancele a finalização da compra (não queremos esperar que tudo seja encerrado).
4. Execute uma limpeza neste checkout cancelado.
5. Agora temos um novo diretório .svn com um banco de dados limpo (embora não haja poucos arquivos)
6. Copie esse arquivo .svn para o diretório de trabalho antigo e corrompido.
7. Execute o svn update e ele deve atualizar seu novo diretório .svn parcial com o seu antigo diretório de trabalho.

Isso é um pouco confuso, em termos de processos. Basicamente, o que estamos fazendo é excluir o .svn corrompido e criar um novo .svn para o mesmo caminho de checkout. Em seguida, movemos esse novo .svn para o diretório de trabalho antigo e o atualizamos para o repositório.

Acabei de fazer isso no TSVN e parece funcionar bem e não requer uma verificação e download completos.

-Jody

Dê uma olhada

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

Resumo da correção do link acima (Agradecimentos a Anuj Varma)

1. Instale o shell da linha de comando sqlite (sqlite-tools-win32) em http://www.sqlite.org/download.html

2. sqlite3 .svn/wc.db "select * from work_queue"

O SELECT deve mostrar sua pasta / arquivo ofensivo como parte da fila de trabalho. O que você precisa fazer é excluir este item da fila de trabalho.

3. sqlite3 .svn/wc.db "delete from work_queue"

É isso aí. Agora, você pode executar a limpeza novamente - e deve funcionar. Ou você pode prosseguir diretamente para a tarefa que estava realizando antes de ser solicitado a executar a limpeza (adicionando um novo arquivo etc.)

Se todo o resto falhar:

1. Confira em uma nova pasta.
2. Copie seus arquivos modificados.
3. Verifique novamente.
4. Coloque a pasta antiga em algum lugar (você nunca sabe que a paranóia é boa) antes de excluí-la e usar a nova.

A versão mais recente (estou usando o 1.9.5) resolve esse problema adicionando uma opção de "Quebrar bloqueios" no menu de limpeza. Apenas verifique se esta caixa de seleção está marcada ao fazer a limpeza.

Esta resposta se aplica apenas a versões anteriores à 1.7 (obrigado @ ŁukaszBachman) .

O Subversion armazena suas informações por pasta (em .svn), portanto, se você está apenas lidando com uma subpasta, não precisa fazer check-out de todo o repositório - apenas a pasta que funcionou:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

Isso fornecerá uma boa cópia de trabalho da pasta borked, mas você ainda terá as alterações em borked_dir.bak. O mesmo princípio se aplica ao Windows / TortoiseSVN.

Se você tiver alterações em uma pasta isolada, consulte o

svn checkout -N borked_dir   # Non-recursive, but deprecated

ou

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'

$ ls -la .svn
$ rm -f .svn/lock

Então

$ svn update

Espero que ajude

Eu tive o mesmo problema. Eu não poderia confirmar, e a limpeza falharia.

Usando um cliente de linha de comando, pude ver uma mensagem de erro indicando que estava falhando ao mover um arquivo de .svn/propspara .svn/prop-base.

Olhei para o arquivo específico e descobri que estava marcado como somente leitura. Após remover o atributo somente leitura, consegui limpar a pasta e confirmar minhas alterações.

É possível que você tenha um problema com dois nomes de arquivos diferentes apenas em maiúsculas. Se você encontrou esse problema, a criação de outro diretório de cópias de trabalho não resolve o problema.

Os sistemas de arquivos atuais do Windows (ou seja, ruins) simplesmente não refletem a diferença entre Filenamee FILEname. Você tem duas correções possíveis:

1. Confira na plataforma com um sistema de arquivos real (baseado em Unix), renomeie o arquivo e confirme as alterações.
2. Quando você está estocado para o Windows, pode renomear arquivos no navegador de repositório Eclipse SVN, que reconhece a diferença e renomeia o arquivo lá.
3. Você pode renomear os arquivos problemáticos também remotamente a partir de qualquer cliente SVN da linha de comando usando svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename

Execute o svn cleanupcomando em um terminal (se houver falha no Eclipse, que foi o meu caso):

~/path/to/svn-folder/$ svn cleanup

Tentei soluções diferentes explicadas aqui, mas nenhuma funcionou .

Equipe de ação → Falha na atualização da cabeça :

svn: E155004: Existem itens de trabalho inacabados em '/ home / user / path / to / svn-folder'; execute 'svn cleanup' primeiro.

Equipe de ação → A limpeza falha com o mesmo erro.

Solução que funcionou para mim: execute o comando svn cleanup em um terminal .

O comando foi bem sucedido.

Em seguida, a equipe → Atualização no Eclipse funcionou novamente.

Nota: minha versão do SVN é 1.9.3.

Verifique também a resposta de Chris se svn cleanupnão funcionar.

Eu tentei fazer svn cleanupatravés do console e recebi um erro como:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

Então, eu criei este arquivo manualmente (vazio) e o fiz svn cleanupnovamente. Desta vez, foi feito OK.

Eu tive o mesmo problema. Para mim, a causa foi um conflito com o EasySVN e (TortoiseSVN ou apenas SVN). Eu tive atualização automática e confirmação com o EasySVN (que não estava funcionando).

Quando desliguei, não consegui limpar, confirmar ou atualizar. Nenhuma das soluções acima funcionou, mas a reinicialização funcionou :)

Eu apenas tive esse mesmo problema no Windows 7 de 64 bits. Executei o console como administrador e excluí o diretório .svn do diretório do problema (ocorreu um erro sobre logs ou algo assim, mas o ignorei). Em seguida, no explorer, excluí o diretório do problema que não estava mais aparecendo como sob controle de versão. Em seguida, executei uma atualização e as coisas prosseguiram conforme o esperado.

Se o problema for a distinção entre maiúsculas e minúsculas (que pode ser um problema ao fazer check-out em um Mac e no Windows) e você não tiver a opção de fazer check-out em um sistema * nix, o seguinte deve funcionar. Aqui está o processo desde o início:

% svn co http://[domain]/svn/mortgages mortgages

(O checkout segue ... então ...)

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

Aqui, o SVN está tentando verificar dois arquivos com nomes semelhantes que diferem apenas entre maiúsculas Header_3_noBookmark.gife minúsculas - e Header_3_nobookmark.gif. Os sistemas de arquivos Mac são padrão para não diferenciar maiúsculas de minúsculas de uma maneira que faz com que o SVN se engasgue em situações como essa. Assim...

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

No entanto, correr svn cleanupnão funciona, como sabemos.

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gifnão é o problema aqui… Simplesmente não pode passar do erro anterior para o próximo arquivo. Portanto, excluí todos os arquivos do diretório que não sejam .svne removi o log SVN. Isso fez a limpeza funcionar, para que eu pudesse fazer check-out e renomear o arquivo incorreto.

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

Depois disso, consegui voltar ao diretório raiz do projeto e executar o svn upcheck-out.

Sempre que tenho problemas semelhantes, uso o rsync (NB: uso Linux ou Mac OS X) para ajudar da seguinte forma:

# Go to the parent directory
cd dir_above_borked

# Rename corrupted directory
mv borked_dir borked_dir.bak

# Checkout a fresh copy
svn checkout svn://... borked_dir

# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/

# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/

Dessa forma, você terá um novo checkout, mas com os mesmos arquivos de trabalho. Para mim, isso sempre funciona como um encanto.

Eu me deparei com isso ultimamente. O truque para mim foi depois de selecionar "Limpar", na caixa de diálogo de opções pop-up, marque "Break Locks" e depois "OK". Limpou com sucesso para mim.

O Subclipse fica confuso com o comportamento de bloqueio verdadeiramente diabólico do Windows. Unlocker é seu amigo. Isso pode encontrar arquivos bloqueados e liberar à força os bloqueios.

(Antes de tentar mover pastas e fazer um novo checkout.)

Exclua a pasta em que os arquivos incorretos estão - sim, até a .svnpasta e faça uma svn cleanupna pasta superior / principal.

Eu enfrentei o mesmo problema. Após algumas pesquisas na Internet, encontrei o artigo abaixo . Então percebi que estava logado como um usuário diferente do usuário em que havia usado para configurar o SVN, basicamente uma questão de permissão.

Quando enfrento esse problema com o TortoiseSVN (Windows), vou ao Cygwin e executo a ' limpeza do svn '; ele limpa corretamente para mim, após o qual tudo funciona no TortoiseSVN.

As respostas aqui não me ajudaram, mas antes de verificar o projeto novamente, fechei e abri o Eclipse (Subversive é meu cliente SVN) e o problema desapareceu.

Pode não ser aplicável em todas as situações, mas quando eu encontrei esse problema recentemente, minha "correção" era atualizar o pacote Subversion no meu sistema. Eu estava executando o 1.4.algo e, quando atualizei para o mais recente (1.6.6 no meu caso), o check-out funcionou.

(Tentei fazer o download novamente, mas um checkout para um diretório limpo sempre ficava no mesmo local.)

Às vezes, o bloqueio somente leitura acontece em unidades de rede com o Windows. Tente desconectar e reconectar novamente. Em seguida, limpe e atualize.

Depois de analisar a maioria das soluções citadas aqui, eu ainda estava recebendo o erro.

A questão era insensível caso OS X . O check-out de um diretório que possui dois arquivos com o mesmo nome, mas com letras maiúsculas diferentes causa um problema. Por exemplo, ApproximationTest.java e Approximationtest.java não devem estar no mesmo diretório. Assim que nos livramos de um dos arquivos, o problema desaparece.

Eu encontrei um problema em que, após uma atualização, o SVN mostrava uma pasta como conflitada. Estranhamente, isso só era visível através da linha de comando - o TortoiseSVN achou que estava tudo bem.

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup, svn revert, svn updateE svn resolveeram todos bem sucedida no que fixa esta.

Acabei por resolver o problema da seguinte forma:

• Procure no diretório .svn "sub_dir"
• Use RC -> Propriedades para desmarcar o sinalizador 'somente leitura' no arquivo de entradas
• Abra o arquivo de entradas e exclua a linha "inacabado ..." e a soma de verificação correspondente
• Salvar e reativar o sinalizador somente leitura
• Repita para o diretório my_dir

Depois disso, estava tudo bem.

Observe que eu não tive nenhuma alteração local; portanto, não sei se você estaria em risco. Eu não usei o método delete / update sugerido por outras pessoas - entrei nesse estado tentando isso no diretório my_dir / sub_dir / sub_sub_dir (que começou com os mesmos sintomas) - então não queria me arriscar a piorar as coisas novamente!

Não é exatamente um tópico, mas talvez seja útil se alguém se deparar com este post como eu.

Não não não! Se você estiver usando o SVN 1.7 ou superior, o comando cleanup deve fazer o trabalho!

Também fiz alguns experimentos e descobri que a solução (pelo menos no Eclipse ) estava executando a limpeza apenas para a pasta especificada na mensagem de erro e não para o projeto inteiro!

eu fiz sudo chmod 777 -R . para poder alterar as permissões. Sem sudo, não funcionaria, me dando o mesmo erro que executar outros comandos.

Agora você pode fazer o que svn updatefor, sem ter que desfazer o diretório inteiro e recriá-lo. Isso é especialmente útil, pois seu IDE ou editor de texto já pode ter certas guias abertas ou problemas de sincronização. Você não precisa descartar e substituir seu diretório de trabalho por esse método.

Resolvi esse problema copiando o diretório .svn de um colega no meu e atualizando minha cópia de trabalho. Foi uma solução agradável, rápida e limpa.

Existem algumas sugestões muito boas na resposta anterior, mas se você estiver tendo problemas com o TortoiseSVN no Windows (um bom produto, mas ...) sempre faça o fallback para a linha de comando e faça uma "limpeza svn" simples primeiro.

Em muitas circunstâncias, o cliente Windows não executará o comando cleanup, mas a limpeza funciona bem usando o utilitário de linha de comando SVN.

Enquanto enfrentava um problema semelhante, a mesclagem manual na exibição de sincronização do repositório ajudou a resolver o problema.

Um nome de arquivo estava em conflito com outro e mencionava claramente o problema. Renomear o arquivo mais recente para um nome diferente o resolveu.