Como você supera o erro svn 'desatualizado'?

Eu tenho tentado mover uma estrutura de diretório de um local para outro no Subversion, mas recebo um Item '*' is out of dateerro de confirmação.

Tenho a versão mais recente em check-out (até onde sei). svn st -unão aparece outras diferenças além dos comandos mv.

Às vezes eu entendo isso com o TortoiseSVN no Windows. A solução para mim é svn updateo diretório, mesmo que não haja revisões para baixar ou atualizar. Faz algo com os metadados, que corrigem magicamente.

Depois de tentar todas as coisas óbvias e algumas das outras sugestões aqui, sem sorte alguma, uma pesquisa no Google levou a este link (o link não está mais funcionando) - O Subversion diz: Seu arquivo ou diretório está provavelmente desatualizado

Em poucas palavras, o truque é ir para o diretório .svn (no diretório que contém o arquivo incorreto ) e excluir o arquivo "all-wcprops" .

Trabalhou para mim quando nada mais fez.

Acredito que esse problema está vindo do arquivo .svn. Ou está incorreto no pai antigo, no novo pai ou no pai antigo. Eu tentaria voltar ao seu ponto de partida. Use uma exportação para obter uma cópia limpa da pasta. Mova a cópia limpa para o novo local e use um add e delete para fazer a movimentação. Isso é fazer manualmente o que o SVN faz, mas pode funcionar.

Eu descobri que isso funciona para mim:

svn update
svn resolved <dir>
svn commit

Tentei atualizar a cópia local e reverter o item em questão e ainda assim obtive o erro 'desatualizado'. Isso funcionou por algum motivo:

svn update --force /path/to/dir/or/file

Eu só tive o mesmo problema em várias pastas e foi isso que fiz para confirmar:

1) Na perspectiva "Team Synchronize", clique com o botão direito do mouse na pasta> Override and Update
2) Exclua a pasta novamente
3) Confirme e seja feliz

Obrigado. Isso apenas resolveu para mim. svn update --force / caminho para o nome do arquivo /

Se o seu arquivo recente no diretório local for o mesmo, não haverá avisos. Se o arquivo for diferente, ele solicita tf, mf etc ... escolhendo mf (mina cheia) garante que nada seja sobrescrito e que eu poderia confirmar quando terminar.

Jay CompuMatter

Consigo resolvê-lo pressionando um botão de atualização

Como sugere o @ Alexander-Klyubin, faça o movimento no repositório. Também será muito mais rápido, especialmente se você tiver uma grande quantidade de dados para mover, porque não precisará transferir todos esses dados pela rede novamente.

svn mv https://username@server/svn/old/ https://username@server/svn/new/

deve funcionar muito bem

Remova seu arquivo ou seu caminho usando antes de executar o comando faça um bk de suas alterações

sudo rm -r /path/to/dir/

depois de :

svn up and commit or delete 

Tem certeza de que deu uma olhada na cabeça e não em uma revisão inferior? Além disso, você fez uma atualização para garantir a versão mais recente?

Há uma discussão sobre isso em http://svn.haxx.se/users/archive-2007-01/0170.shtml .

Execute a movimentação diretamente no repositório.

Há pelo menos uma outra causa do erro "desatualizado" da mensagem. No meu caso, o problema era .svn / dir-props, criado com a execução "svn propset svn: ignore -F .gitignore." pela primeira vez. Excluir .svn / dir-props parece uma má idéia e pode causar outros erros; portanto, é melhor usar "svn propdel" para limpar o "svn propset" incorreto.

# Normal state, works fine.
> svn commit -m"bump"  
Sending        eac_cpf.xsl
Transmitting file data .
Committed revision 509.

# Set a property, but forget to commit.
> svn propset svn:ignore -F .gitignore .
property 'svn:ignore' set on '.'

# Edit a file. Should have committed before the edit.
> svn commit -m"bump"                   
Sending        .
svn: Commit failed (details follow):
svn: File or directory '.' is out of date; try updating
svn: resource out of date; try updating

# Delete the property.
> svn propdel svn:ignore .              
property 'svn:ignore' deleted from '.'.

# Now the commit works fine.
> svn commit -m"bump"     
Sending        eac_cpf.xsl
Transmitting file data .
Committed revision 510.

Se você estiver usando a ponte svn do github, é provável que algo tenha mudado no lado do github. A solução é simples, basta executar svn switch, o que permite que ela se encontre adequadamente, atualizar e tudo funcionará. Basta executar o seguinte a partir da raiz do seu checkout

svn info | grep Relative 
svn switch path_from_previous_command
svn update

ou

svn switch `svn info | grep Relative | sed 's_.*: __'`
svn update

A base para esta solução vem do blog de Lee Preimesberger

Você está usando svn mv, ou apenas mv? Eu acho que usar apenas mvpode causar esse problema.

Mudei o diretório para a minha máquina local por segurança, então svn excluiu o diretório estúpido e, em seguida, cometeu. Quando tentei adicionar a pasta da minha máquina local, AINDA gerou o erro (a movimentação do SVN fez a mesma coisa quando tentei renomear a pasta). Então, eu reverti e fiz um mkdir DIRNAME, adicionei e cometi. Então eu adicionei o conteúdo e o cometi, e funcionou.

Recebi esse erro aleatoriamente depois de excluir alguns diretórios, cada um contendo alguns arquivos. Excluí os diretórios através do Netbeans e percebi que ele não os excluía. Parecia apenas excluir tudo dentro dos diretórios e remover a referência ao diretório no Netbeans. Eles ainda existiam no sistema de arquivos. Verifique se eles foram excluídos do sistema de arquivos e tente confirmar novamente.

Se uma vez resolveu um problema semelhante, basta fazer o check-out de uma nova cópia de trabalho e substituir o diretório .svn, lançando os erros de confirmação por este recém-retirado. O motivo, no meu caso, foi que, após uma corrupção e restauração de um repositório de um backup, a cópia de trabalho estava apontando para uma revisão que não existia no repositório restaurado. Também obtive erros de "item desatualizado". A atualização da cópia de trabalho antes da confirmação não resolveu isso, mas a substituição do .svn conforme descrito acima.

Eu fiz isso e funcionou para mim:
1. Faça um backup do seu arquivo. Você pode simplesmente copiar seu código para um arquivo de texto.
2. Clique com o botão direito do mouse no arquivo que deseja confirmar >> Equipe >> Mostrar histórico. 3. No painel "Mostrar histórico", você verá todas as revisões desse arquivo. Clique com o botão direito do mouse na última revisão do arquivo >> Obter revisão: Ele substituirá as alterações locais.
4. Agora, mescle seu código com o arquivo mais recente com o arquivo de backup (etapa 1).
5. Sincronize e confirme o arquivo recém-mesclado.

Atualize seu servidor e cliente para o Subversion 1.9.

Se o out of dateerro ocorrer aleatoriamente quando normalmente não deveria, quando você executa o commit, isso pode indicar que você está usando um cliente ou servidor antigo ou desatualizado do Subversion 1.7 ou anterior.

Você deve atualizar o servidor e os clientes para resolver o problema. Veja a entrada relevante das Notas de Versão do Subversion 1.9: Erros "Desatualizados" ao confirmar sobre HTTPv1 .

O erro ocorre porque você não atualizou esse arquivo específico, primeiro atualize e somente você poderá confirmar o arquivo.

Tentei tudo, exceto alterar diretamente .svn. Nada ajudou, então aqui está a minha solução.

No Eclipse> Janela> Mostrar Visualização> Histórico , vi que o arquivo não está na Revisão mais recente, embora eu tenha feito vários svn "Substituir e atualizar" / "Reverter" / excluir arquivo e fazer checkout.

Então eu fui ao Package Explorer> clique com o botão direito do mouse no arquivo> Replace with> Latest from Repository .

Outra olhada na Exibição do histórico mostrou que o arquivo estava agora na última revisão.

"Clean Up" Isso o levará à pista.

Clique com o botão direito do mouse na pasta svn e clique em 'Limpar', faça isso se você receber esse erro.

Isso aconteceu quando eu atualizei um ramo de uma versão anterior com arquivos do tronco. Usei o Windows Explorer para copiar pastas da minha pasta de checkout de tronco e colei-as na minha visualização do Eclipse da pasta de checkout de ramificação de liberação. Agora, o Windows Explorer estava configurado para não mostrar arquivos "ocultos" começando com ".", Portanto, eu estava alheio a todos os arquivos .svn incorretos sendo colados na minha pasta de checkout do ramo de lançamento. Doh!

Minha solução foi afastar o projeto Eclipse danificado, verificar novamente e copiar os novos arquivos com mais cuidado. Eu também mudei o Windows para mostrar arquivos "ocultos".

Eu recebi esse erro ao tentar confirmar alguns arquivos, apenas um arquivo / pasta que não existia na minha cópia de trabalho. REALMENTE não queria passar pelo incômodo de mover os arquivos e verificar novamente; no final, acabei editando o arquivo .svn / inputs e removi a referência do diretório incorreto.

No meu caso, apenas a exclusão da versão local e o check-out de nova cópia era uma solução.

Acabei de receber este erro. O que eu recomendo é que você verifique primeiro no seu servidor se o arquivo original está lá. Às vezes, as alterações não são feitas na sua pasta local. Se essa for a sua situação, basta excluir sua pasta e fazer o checkout novamente.

Para resolver, precisava reverter o arquivo com problema e atualizar minha cópia de trabalho; depois modifiquei o arquivo novamente e, após essas etapas, o erro não ocorreu mais.

Basta fazer o svn na linha de comando ou, se você estiver no Windows, selecione a opção svn update.

• Feito isso, você poderá executar outras ações, como confirmação e outras.

Acabei de receber isso enquanto tentava commitde um trunkdiretório. Fazer a svn updatepartir do trunkdiretório não resolveu o erro; no entanto, fazer a svn updatepartir do diretório pai (onde o .svndiretório pertence) resolveu o erro.

Meu palpite sobre o que aconteceu (um caso de uso entre outros, pode haver várias razões para esse “svn: E160024: recurso desatualizado; tente atualizar”): junto com trunk, havia um branchesdiretório. Puxei um branches/branch-1em masterno GitHub. Fazer a svn updatepartir do diretório pai (ou seja, a raiz da minha cópia de trabalho), em vez de, trunkparece ter feito algo branchesalém disso trunk. Quando tentei commitnovamente, não houve erro.

No entanto, como eu disse acima, este é um caso entre provavelmente muitos outros.

Nota lateral: ao contrário do que alguém sugeriu, não acredito que seja uma boa ideia tocar manualmente no .svndiretório.