Pergunta

Eu recebo este erro quando eu faço um svn update:

Working cópia XXXXXXXX bloqueado por favor executar o comando "Limpeza"

Quando eu executar a limpeza, eu recebo

Cleanup não conseguiu processar o seguintes caminhos: XXXXXXXX

Como faço para sair deste loop?

Foi útil?

Solução

Uma abordagem seria:

  1. cópia editada itens para outro local.
  2. Excluir a pasta que contém o caminho problema.
  3. Atualização da pasta que contém através Subversion.
  4. Copie seus arquivos de volta ou mudanças de mesclagem conforme necessário.
  5. Commit

Outra opção seria a de excluir a pasta de nível superior e confira novamente. Esperemos que ele não vem para que embora.

Outras dicas

Para mim, o truque era correr svn cleanup no topo da minha cópia de trabalho, e não na pasta onde eu estava trabalhando o tempo todo antes que o problema ocorreu.

Procure na sua pasta .svn, haverá um arquivo em que chamou lock. Excluir esse arquivo e você será capaz de atualizar. Pode haver mais arquivos de bloqueio no diretório .svn de cada subdiretório. Eles precisarão de apagar também. Isso poderia ser feito como um lote muito simplesmente a partir da linha de comando com por exemplo.

find . -name 'lock' -exec rm -v {} \;

Note que você está editando arquivos manualmente na pasta .svn. Eles foram colocados lá por uma razão. Essa razão pode ser um erro, mas se não você poderia ser prejudicial a sua cópia local.

Fonte: http://www.svnforum.org/2017/viewtopic. php? p = 6068

No meu caso eu resolvido apagando manualmente um registro no SQLite ".svn \ wc" record bloqueio de arquivo na tabela de WC_LOCK.

Eu abri o arquivo "WC" com o editor SQLite e executado

delete from WC_LOCK

Captura de tela mostrando todas as entradas da purificação dos WC_LOCK

comentário

A seguir eakkas 's , pode ser necessário apagar todas as entradas da tabela WORK_QUEUE também.

A maneira mais fácil de sempre:

  1. Vá para diretório pai (Pasta) de Projeto .
  2. Pres Botão direito do mouse
  3. Pressione TortoiseSVN seguida, pressione Limpar ...
  4. diálogo até Limpo iria aparecer automaticamente
  5. Selecionar Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays, Include externals
  6. Pres OK

Você fez o seu trabalho com sucesso.

Verifique as capturas de tela para sua referência.

Primeiro passo:

enter descrição da imagem aqui

Segunda etapa: Ative a opção de bloqueio Break (segunda caixa de seleção na janela pop-up de limpeza) enter descrição da imagem aqui

Espero que este irá ajudá-lo muito.

Um colega de trabalho constantemente vê esta mensagem, e para ele é porque ele apagou um diretório sob SVN controle de versão sem excluí-lo do SVN, e depois criado um novo diretório em seu lugar não sob a versão controle, com o mesmo nome.

Se este for o seu problema ...:

Existem diferentes maneiras de corrigi-lo, dependendo de como / por que o diretório foi substituído.

De qualquer maneira, você provavelmente irá precisar:

A) Renomeie o diretório existente para um nome temporário

B) Fazer um revert SVN para recuperar o diretório excluído do sistema de arquivos, mas não de SVN

A partir daí, você faria qualquer

A) Copie os arquivos relevantes para o diretório que foi excluído

B) Se você teve uma mudança significativa de conteúdo no diretório, não um SVN excluir no original, commit e mudar o nome do novo diretório de volta para o nome desejado, seguido de um SVN adicionar para obter que um sob controle de versão.

Para mim nenhuma das soluções acima funcionou. I encontrada uma solução por fechaduras de ruptura. Quando eu realizada a limpeza svn, eu selecionei "Break Locks", juntamente com "Clean up trabalhando status da cópia".

 enter descrição da imagem aqui

Este trabalhou para mim.

  1. Vá para a pasta raiz,
  2. Botão direito do mouse e limpeza
  3. Verifique todas as opções disponíveis
  4. Pressione OK

Depois de limpeza que irá permitir que você atualize para a versão mais recente.

Para mim, era realmente culpa de tartaruga, espécie de. Tortoise apenas reclamou "não pode limpar, executar a limpeza", mas quando eu corri na linha de comando (limpeza svn), ele me disse claramente que não podia apagar alguns arquivos que estavam em uso, a solução para o que era óbvio. Uma vez que eu fechei Visual Studio (que estava mantendo os arquivos abertos), então a limpeza funcionou bem.

Outros programas também podem manter arquivos aberto no repo causando esse problema. Excel segurando um aberto xls era um culpado em outra instância por isso pode ser sábio para fechar todos os programas que possam estar usando nada no repo ou até mesmo reiniciar para forçar programas para fechar e depois tentar a limpeza novamente.

Eu tive esse problema porque as pastas externas não quer ser vinculado a uma pasta existente. Se você adicionar um svn: linha de propriedade externos, onde o destino é uma pasta existente (controle de versão ou não-versionadas), você vai obter o SVN woring Copiar bloqueado erro. Aqui uma limpeza também irá dizer-lhe que esta tudo bem, mas ainda a atualização não funcionará.

Solução: Excluir a pasta incomodando a partir do repositório e fazer uma atualização na pasta raiz onde a propriedade svn: externos está definido. Isto irá criar a pasta e tudo ficará bem novamente.

Este problema surgiu para mim, porque svn: externals para arquivos requer a pasta de destino a ser versão controlada. Depois notei que isso não funciona em diferentes repositórios, eu swaped de arquivos externos para pasta externa e meteu nesta confusão.

A maneira mais fácil de fazer isso é mostrar pastas ocultos e, em seguida, abra a pasta .svn. Você deverá ver um arquivo de zero KB chamado "bloqueio" apagar isso vai resolver o problema

me deparei com o mesmo problema exato usando SVN 1,7 e nenhuma das correções mencionadas acima funcionou.

Em primeiro lugar, certifique-se de backup de todo o conteúdo editado.

Depois de passar um par de horas (não baixar novamente tudo como meu ramo é mais de 6 GB de tamanho), descobri que há um arquivo db chamado de "wc" na pasta .svn do seu ramo.

Abra o arquivo db utilizando qualquer gestor db (i usado plug-in gerente de SQLite do Firefox) e navegue para a mesa WC_LOCK. Esta tabela terá as entradas para os bloqueios adquiridos. Excluir os registros da tabela e está feito:)

Quando eu tenho esse problema, eu acho que executa o comando de limpeza diretamente sobre o caminho problema geralmente parece trabalho. Então eu vou executar a limpeza da raiz trabalhar novamente, e ele vai reclamar algum outro diretório. e eu só repetir até parar reclamando.

Se você estiver em uma máquina Windows, Ver o repositório através de um navegador e você pode muito bem ver dois arquivos com o mesmo nome, mas usando diferentes casos. Subversion é sensível a maiúsculas e Windows não é assim que você pode obter um bloqueio quando o Windows pensa que está puxando para baixo o mesmo arquivo e Subversion não. Apagar os nomes de arquivos duplicados no repositório e tente novamente.

Eu fiz isso por apenas criar uma nova pasta, verificando o projeto, copiando os arquivos atualizados para a nova pasta.

Foi corrigido com um check-out fresco.

Você está usando TortoiseSVN e apenas atualizado? Eu tive esse problema antes, quando se deslocam 1,4-1,5 e não reiniciar. (Tente um reboot).

A razão que você precisa para reiniciar é porque o arquivo de cache recebe toda funk.

Caso contrário, para seguir em frente, a exportação que o trabalho de cópia em uma nova pasta (não copiar o .svn pastas ocultas), re-check-out do projeto, e mover todo o seu código de volta, em seguida, efectuar a sua cometer.

apenas excluir as pastas .svn, em seguida, executar uma limpeza no diretório pai. Funciona perfeitamente !!

Em versões em Mac OS: Ação -> cópia de trabalho Limpeza de eclusas em ...

muitas vezes eu recebo essa questão. Meu padrão que causa problemas de limpeza.

  1. I arquivo de imagem aberto no espectador.
  2. I arquivo de imagem / pasta de exclusão.
  3. Eu estou tentando cometer / update

O encerramento visualizador de imagens onde excluídos arquivo é aberto resolve o problema. Talvez outro software pode bloquear a limpeza da mesma forma.

Em geral. Acredito que reiniciar computador pode ajudar nesses casos.

SVN normalmente atualiza sua estrutura interna (.svn / prop-base) dos arquivos em uma pasta antes que os arquivos reais é obtido a partir do repositório. Depois que os arquivos são obtidos isso será esclarecido. Freqüentemente, o erro é lançado porque o "update" falhou ou prematuramente cancelada durante o progresso da atualização.

  1. Verifique todos os arquivos são listados sob .svn diretório / prop-base de
  2. Remova quaisquer arquivos que não estão sob a pasta
  3. Cleanup
  4. Atualização

Agora, a atualização deve funcionar.

teve o mesmo problema porque eu exportados uma pasta em uma pasta controlada por versão. Teve de excluir a pasta de TortoiseSVN, exclua a pasta do sistema de arquivos (TortoiseSVN não gosta subpastas unversioned ... Por que não ???)

Não exclua a sua solução!

na .svn pasta você tem um arquivo chamado bloqueio é 0 bytes longo

Você pode excluir todos esses arquivos de todas as pastas .svn em sua solução e que irá trabalhar

Ele trabalhou no meu caso

Em lugar unversioning dos arquivos e um check-out fresco no mesmo local, tem resolvido este problema para mim.

Em TortoiseSVN, para fazer uma unversioning no local, arraste o botão direito na pasta raiz da cópia de trabalho a partir da lista de arquivos para si mesmo na árvore de diretórios, e escolha "SVN Export versionadas itens aqui" no menu pop-up . avisos TortoiseSVN que o destino é o mesmo que a fonte, e sugere unversioning a cópia de trabalho.

Depois de unversioning, fazer um novo check-out na mesma pasta (que agora contém uma cópia sem versões de todos os arquivos que você tinha). TortoiseSVN irá avisá-lo que você está verificando em uma pasta existente, mas você pode ir em frente.

Depois disso, limpezas, atualizações e outras operações funcionou sem problemas. Uma vez que ambos os passos acima preservar modificações locais, não deve haver qualquer perda de informação (mas apoiar a cópia de trabalho antes que este pode, contudo, ser uma boa idéia).

Um aviso: Se a cópia de trabalho contém versões mistas ou alterações de propriedade não confirmadas, de que as informações serão perdidas. Para mim, isso não é uma ocorrência comum, e dada a escolha de uma cópia de trabalho corrompido ou perder alterações de propriedade não confirmadas, que tendem a optar por este último.

Eu tive esse problema, onde o "clean up" funcionou, mas o "update" continuaria a falhar. A solução que funcionou foi o de excluir a pasta em questão através do Windows Explorer, não de exclusão (que marca a exclusão como algo a se comprometer com o repositório, e então eu fiz um "checkout" essencialmente "update" a pasta do repositório TortoiseSVN.

Mais informações sobre a diferença entre um O / S de exclusão e um SVN excluir aqui: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug -rename.html

Notavelmente:

Quando você TortoiseSVN ? Excluir um arquivo, ele é removido de sua cópia de trabalho imediatamente, bem como sendo marcado para exclusão no repositório no próximo commit.

E:

Se um arquivo é excluído via explorador em vez de usar o menu de contexto TortoiseSVN, a caixa de diálogo mostra os arquivos comprometer e permite que você removê-los do controle de versão muito antes da submissão. No entanto, se você atualizar sua cópia de trabalho, o Subversion irá detectar o arquivo ausente e substituí-lo com a versão mais recente do repositório.

Se você estiver em Linux, tente o seguinte:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Em seguida, execute o comando cleanup nesse diretório, em seguida, tentar atualização.

Eu fiz o seguinte para corrigir o meu problema:

  1. Renomeado a pasta ofensiva, colocando um "_" na frente do nome da pasta.
  2. Será que a "Clean Up" da pasta pai.
  3. Renomeado a pasta ofender voltar a ele nome original.
  4. Será que um commit.

No Solution Explorer, clique direito sobre o projeto, no sub-menu de abertura de cliques em subversão e selecione clean-up. Ele vai resolver o problema, como ele fez por mim. Espero que isso vai funcionar.

Para fazer a limpeza

  1. Excluir a pasta .svn.

  2. Faça o svncheckout na pasta raiz.

  3. Tente realizar a operação de limpeza.

Este foi o meu problema resolvido.

Para mim, o problema era com unidade de disco completamente cheio (inodes linux no meu caso), quando eu apagar algumas pastas que começou a trabalhar novamente.

O erro foi a seguinte (em qualquer acção SVN):

$ svn cleanup
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy locked; try running 'svn cleanup' on the root of the working copy ('/my/directory') instead.
svn: E155004: Working copy '/my/directory' locked
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file

Eu tive isso sob TortoiseSVN eo erro foi relacionado a um novo diretório que eu tinha criado ao abrigo de um novo projeto. Eu tinha acabado de criar este projeto, então não havia nenhuma maneira este diretório existia antes. Olhei no navegador de repositório e a nova pasta era de fato já no repositório, mas TortoiseSVN não mostrá-lo como comprometido.

A fim de contornar o problema, desde que eu tinha acabou de criar a pasta de qualquer maneira, eu apaguei-lo no repositório, e depois fez um commit. Funcionou muito bem.

Uma vez que eu fiz isso fora do Visual Studio, então eu tive que reiniciar Visual Studio para que possa descobrir tudo novamente.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top