Pastas obstruídas no Subversion

O que diabos "obstruído" significa quando você tenta verificar o Subversion? Vejo duas pastas em vermelho com o status de texto "obstruído". Não vejo o que isso significa em nenhum lugar nos documentos.

Quando tento o cleanupcomando, obtenho "o nome da pasta não é um diretório ativo". Esta é uma pasta que acabei de criar no VS e, quando tento adicioná-la ao Subversion, gera esse erro. Todas as outras pastas estão bem.

ocorre quando você excluiu ou moveu os subdiretórios .svn (sem passar pelos comandos SVN), portanto, o SVN tem uma visão corrompida da cópia de trabalho.

Tente uma limpeza primeiro e, se isso não resolver, reverta (ou atualize) o diretório para restaurar as pastas .svn do subdiretório.

Sem saber o que causa isso, a solução pode ser exportar a cópia de trabalho (todo o check-out que você possui localmente) para outro lugar.

Se você estiver usando o tortoisesvn, terá a opção de "exportar arquivos sem versão", mas acho que, ao fazê-lo a partir da linha de comando, ele só exporta arquivos com versão, para que você possa ter uma tarefa trabalhosa ao copiar arquivos sem versão manualmente .

Depois de feito, verifique uma cópia de trabalho limpa e solte o backup exportado que você possui por cima. É muito importante que o backup não tenha pastas .svn.

Eu já vi esses erros antes quando as pessoas fazem check-out de cópias de trabalho em outras cópias de trabalho ou qualquer outra coisa que corrompa as entradas .svn.

Teve o mesmo problema e o corrigiu assim:

• renomeou o diretório obstruído
• criou o diretório com seu nome original no SVN (por exemplo, svn mkdir)
• atualizei a pasta pai, para que o dir recém-criado apareça na minha cópia de trabalho
• copiou os arquivos do diretório obstruído para o recém-criado e os comprometeu

Se você estiver em um sistema * nix, verifique se não criou um arquivo, adicione-o ao SVN e exclua-o, substituindo-o por uma pasta com o mesmo nome. Não ajuda o OP, mas espero que isso poupe bastante estresse a alguém.

Isso significa que, por algum motivo, ocorreu um conflito durante a operação. Verifique se há um arquivo ou pasta não versionada existente com o mesmo nome que um versão com versão.

(Parafraseado do arquivo de ajuda do cliente Tortoise SVN)

Nada funcionou para mim, então eu fiz o seguinte:

• exportados com os arquivos não versionados em um novo local
• renomeou a pasta existente
• moveu a pasta do local de exportação no projeto
• renomeou a nova pasta
• adicionar, confirmar
• removeu a pasta antiga renomeada
• renomeou a nova pasta
• comprometer

Existem diferentes variações de cenário que podem causar essa situação. Aqui está um exemplo:

Acabei com o! marque em um diretório que foi renomeado de www para www_a sem usar o comando 'svn rename':

1. Renomeie o diretório atual que leva o nome original, por exemplo, para www_b
2. Renomeie www_a novamente para www
3. Certifique-se de fazer 'svn update' ou 'svn revert' dentro do diretório www
4. Exclua o diretório www atualizado sem usar 'svn delete'
5. Vá para o diretório pai e emita 'svn update'
6. Isso restaurará o diretório www original
7. Desta vez, use 'svn rename' para renomear www para www_a
8. Renomeie www_b novamente para www
9. Use 'svn add' para adicioná-lo ao repositório

Você deve obter um diretório de trabalho svn correto neste momento. E aprenda uma coisa ou duas sobre como resolver a confusão do diretório svn.

Enfrentou esse problema em uma máquina Windows.

Eu havia verificado o diretório antes de verificar o projeto inteiro ao qual ele pertencia. Isso causou o problema 'obstruído' para mim.

Eu simplesmente excluí essa pasta e executei uma atualização a partir da raiz (dessa pasta). Funcionou bem.

Comandos como limpeza etc. não funcionaram para mim.

Alguma palavra de cautela:

1. Isso é caro se a pasta for grande.
2. Isso fará com que você perca todas as alterações, se houver alguma.

Muito bem sucedida.

Também vi isso no Windows quando criei um link simbólico para um diretório de repositório; nesse caso, a raiz do repositório é vista como "obstruída". Isso não parece ter nenhum efeito, no entanto.

Passos para reproduzir:

1. Finalize seu repo

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Verifique se o seu diretório está OK

   cd plugin_dir
   svn st -u
   

   A saída deve ser

   Status against revision: 1234
   

3. Crie o link simbólico (que mostra o problema)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   A saída será

   ~           1234  .
   Status against revision: 1234
   

Eu me deparei com esse problema ao colar na pasta com subdiretórios minha cópia de trabalho usando meu cliente de FTP - sabia que tinha estragado assim que apertei o botão de transferência ... os perigos de trabalhar tarde demais.

Eu tentei todas as sugestões acima e outras encontradas online sem sucesso. Cada opção produziu o erro de que meu diretório estava bloqueado e a operação não pôde ser executada.

Entrei na minha cópia do Time Machine, restaurei o diretório e estava pronto. Limpei a cópia de trabalho por precaução, atualizei meus arquivos corretamente e estava de volta aos negócios.

Freqüentemente, temos várias ramificações em movimento ao mesmo tempo. Para me salvar alternando ou mexendo na configuração do IIS, verifico cada ramificação em uma pasta separada. Em seguida, uso o link de diretório para conectar essas pastas ao caminho principal configurado no IIS.

Então, para mim, o diretório vinculado sempre tem uma exclamação amarela e é marcado como obstruído. Acredito que seja porque foi tecnicamente criado / movido para fora do SVN.

Recebo esse status "obstruído" nos diretórios quando atualizo para um CMS (WordPress ou Drupal) por meio da interface da Web - o aplicativo não sabe que seu código é na verdade uma cópia de trabalho do subversion; portanto, ao atualizar um plug-in, ele remove os plug-ins diretório (incluindo o .svndiretório) e cai em um novo diretório da nova versão do plug-in.

Para recuperar esse .svndiretório, no diretório que contém o diretório obstruído. Eu faço um checkout com --force. Por exemplo, se plugin_direstiver marcado como "~", no diretório pai, eu corro:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Todos os arquivos já existentes são deixados em paz e marcados com "E" na saída do comando checkout (marcado como "M" quando executo svn status).

Às vezes, tenho que voltar e adicionar arquivos novos com a atualização; ou excluir arquivos que devem ser excluídos como parte da atualização, pois eles reapareceram quando eu fiz o checkout. Acredito que estes estejam marcados como "A" no checkout, mas um subsequente svn statusnão os mencionará.

Encontrei isso no Eclipse, onde alguns arquivos foram marcados com um ponto de exclamação vermelho. O problema era uma pasta .svn perdida no diretório de origem. Excluí a pasta .svn, atualizei o eclipse e pude verificar os arquivos.

Isso também pode acontecer quando você atualiza seu subversion para uma versão que o XCode não suporta.

Aqui está a maneira mais simples (e mais segura) que eu encontrei para resolver isso:

1. Renomeie temporariamente o arquivo ou diretório incorreto (ou um diretório pai) que está obstruído (por exemplo, adicione ".backup").
2. Exclua todos os .svndiretórios dentro do diretório renomeado (se aplicável).
3. svn revert o objeto renomeado (e agora ausente) da etapa 1.
4. svn delete o objeto revertido.
5. Renomeie o backup da etapa 1 para seu nome original.
6. Adicione e faça o check-in do objeto renomeado novamente em svn como um novo objeto.

Isso ocorreu quando substituí um arquivo por uma pasta com o mesmo nome. Resolvido excluindo o arquivo antigo, confirme e adicione o novo. Um pouco hacky, mas funcionou para mim :)

Excluí .svn em diretórios obstruídos e atualizo-o de fora. Então, o comando svn externo reconhecerá esses arquivos.