Reparar soma de verificação SVN

Question

Estou usando o subclipse no Flex Builder 3 e recentemente recebi este erro ao tentar confirmar:

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

Eu trabalhei em torno disso:

1. Confirmando todos os outros arquivos alterados, omitindo o problemático.
2. Copiando o conteúdo do arquivo de problema para uma janela TextMate
3. Excluindo meu projeto no FlexBuilder/Eclipse
4. Verificando meu projeto recém-saído do SVN
5. Copiando o texto do arquivo de problema de volta da janela TextMate
6. Confirmando as alterações.

Funcionou, mas não posso deixar de pensar que existe uma maneira melhor.O que realmente está acontecendo para causar o erro svn:checksum e qual é a melhor solução.

Talvez mais importante – isto é um sintoma de um problema maior?

Answer 1

O arquivo no diretório .svn que controla o que você fez check-out, quando, qual revisão e de onde foi corrompido de alguma forma, para aquele arquivo específico.

Isso não é mais perigoso ou crítico do que o problema normal de arquivo estranho e pode ser devido a vários problemas, como um programa de subversão morrendo no meio da mudança, interrupção de energia, etc.

A menos que aconteça mais, eu não daria muita importância a isso.

Isso pode ser corrigido fazendo o que você fez, fazendo uma cópia de seus arquivos de trabalho, verificando uma nova cópia e adicionando os arquivos modificados novamente.

Observe que isso pode causar problemas se você tiver um projeto ocupado onde normalmente teria que mesclar as alterações.

Por exemplo, você e um colega verificam uma nova cópia e começam a trabalhar no mesmo arquivo.Em algum momento, seu colega verifica suas modificações.Ao tentar fazer o mesmo, você terá o problema de soma de verificação que possui.Se você agora fizer cópias de seus arquivos alterados, faça uma nova verificação, então o Subversion perderá o controle de como suas alterações devem ser mescladas novamente.

Se você não encontrou o problema neste caso, quando você fizer o check-in de suas modificações, você precisará atualizar sua cópia de trabalho primeiro e possivelmente lidar com um conflito com seu arquivo.

No entanto, se você fizer uma nova verificação, completa com as alterações de seus colegas, agora parece que você removeu as alterações dele e as substituiu pelas suas.Sem conflitos e sem indicações da subversão de que algo está errado.

Answer 2

Há também uma causa mais simples para isso do que apenas bugs ou corrupção de disco, etc.Acho que a causa mais provável para isso acontecer é quando alguém escreve uma substituição de texto recursiva na cópia de trabalho, sem excluir os arquivos .svn.
Isso significa que as cópias originais dos arquivos (basicamente a versão BASE dos arquivos, armazenada na área administrativa .svn) são modificadas e isso invalida a soma MD5.

@André Hedges:isso também explica por que sua solução corrige isso.

Answer 3

O SVN mantém cópias originais de todos os arquivos que você faz checkout enterrados nos diretórios .svn.Isso é chamado de base de texto.Isso permite diferenças e reversões rápidas.Durante várias operações, o SVN fará somas de verificação nesses arquivos baseados em texto para detectar problemas de corrupção de arquivos.

Em geral, uma incompatibilidade de soma de verificação SVN significa que um arquivo que não deveria ter sido alterado foi alterado de alguma forma.O que isso significa?

1. Corrupção de disco (HDD ou cabo IDE defeituoso)
2. RAM ruim
3. Link de rede ruim
4. Algum tipo de processo em segundo plano alterou um arquivo pelas suas costas (malware)

Tudo isso é ruim.

NO ENTANTO, Acho que seu problema é diferente.Veja a mensagem de erro.Observe que ele esperava alguns hashes MD5, mas retornou 'nulo'.Se este fosse um simples problema de corrupção de arquivo, eu esperaria que você tivesse dois hashes MD5 diferentes para o esperado/obtido.O fato de você ter um 'nulo' implica que algo mais está errado.

Eu tenho duas teorias:

1. Bug no SVN.
2. Algo tinha um bloqueio exclusivo no arquivo e o MD5 não poderia acontecer.

No caso nº 1, tente atualizar para a versão mais recente do SVN.Talvez também poste isso na lista de discussão do svn-devel (http://svn.haxx.se), para que os desenvolvedores possam ver.

No caso nº 2, verifique se algo está com o arquivo bloqueado.Você pode baixar uma cópia do Process Explorer para verificar.Observe que você provavelmente deseja ver quem tem bloqueio no base de texto arquivo, não o arquivo real que você estava tentando enviar.

Answer 4

Ocasionalmente recebo coisas semelhantes, geralmente com arquivos que ninguém acessa há semanas.Geralmente, se você sabe que não está trabalhando no diretório em questão, basta excluir o diretório com o problema e executar

svn update

para recriá-lo.

Se você tiver alterações ativas no diretório, como lassevk e você mesmo sugeriram, será necessária uma abordagem mais cuidadosa.

De modo geral, eu diria que é uma boa ideia não deixar os arquivos editados não confirmados e manter a cópia de trabalho organizada - não adicione um monte de arquivos extras na cópia de trabalho que você não vai usar.Comprometa-se regularmente e, se a cópia de trabalho falhar, você pode simplesmente excluir tudo e começar de novo sem se preocupar com o que pode ou não estar perdendo e sem a dor de tentar descobrir quais arquivos salvar.

Answer 5

Ainda hoje, consegui me recuperar desse erro verificando uma cópia do diretório corrompido em /tmp e substituindo os arquivos em .svn/text-base pelos apenas co'ed.Eu escrevi o procedimento com alguns detalhes aqui no meu blog. Eu estaria interessado em ouvir de usuários mais experientes do SVN quais são as vantagens e desvantagens de cada abordagem.

Answer 6

tentar:svn up --force arquivo.c

Isso funcionou para mim sem ter que fazer nada extra

Answer 7

Observei muitas soluções, desde a correção do arquivo .svn/entries até o novo checkout.

Pode ser uma nova forma (graças ao meu colega):

- go to work directory where recorder/expected checksum issue occured
- call "svn diff" and make sure that there isnt any local modifications
- cd ..
- remove trouble file's directory with "rm -rf"
- issue "svn up" command, svn client will restore new fresh files copies

Answer 8

Matt, existe uma maneira mais fácil do que você descreveu - modificar a soma de verificação no arquivo .svn/entries.Aqui está a descrição completa:http://maymay.net/blog/2008/06/17/fix-subversion-checksum-mismatch-error-by-editing-svnentries-file/

Answer 9

Outra solução alternativa, possivelmente ainda mais assustadora, para conflitos de soma de verificação que encontrei é a seguinte:

EMBARGO: Certifique-se de que sua cópia local seja a versão mais conhecida E que qualquer outra pessoa em seu projeto saiba o que você está fazendo!(caso isso ainda não fosse óbvio).

se você sabe que sua cópia local do arquivo é "a boa", você pode excluir diretamente o arquivo do servidor SVN e forçar a confirmação de sua cópia local.

sintaxe para exclusão direta:

svn delete -m "deleting corrupted file XXXX" 
svn+ssh://username@svnserver/path/to/XXXX

boa sorte!

J.

Answer 10

Como uma alternativa para verificar uma nova cópia (o que eu também tive que fazer depois de tentar todas as outras opções) e mesclar todas as alterações que você salvou anteriormente nela, a abordagem a seguir funcionou da mesma maneira, mas me economizou uma quantidade considerável de tempo e possivelmente alguns erros:

1. Confira uma nova cópia de trabalho
2. Copie a pasta .svn de sua cópia nova para sua cópia corrompida
3. Voilá

Claro, você deve fazer backup de sua cópia de trabalho original corrompida, apenas para garantir.No meu caso, fiquei à vontade para retirá-lo depois de terminar, pois tudo correu bem.

Answer 11

Isso acontecerá quando a pasta .svn for corrompida.Solução:Remova toda a pasta que contém o arquivo e faça check-out da pasta novamente.

Answer 12

Tive esse problema, nossas VMs de desenvolvimento são todas *nix nossas estações de trabalho win32.Alguns tolo (s) criaram arquivos com o mesmo nome (caso diferente) na caixa *nix de repente checkouts no win32 explodir ...Porque Win não sabe qual dos 2 arquivos de mesmo nome para MD5 contra, os checkouts no *nix foram bons ...deixando-nos coçar a cabeça um pouco

Consegui atualizar o repositório na caixa win copiando as pastas ".svn" de uma caixa * nix com uma boa cópia de trabalho.ainda não vimos se o repositório pode ser limpo a ponto de podermos fazer uma verificação completa novamente

Answer 13

Outra maneira fácil....

1. Atualize seu projeto para obter a versão mais recente
2. verificar a mesma versão em outra pasta
3. substitua a pasta .svn do novo checkout para a cópia de trabalho (substituí os arquivos .svn-base)

Answer 14

1. Confira apenas a pasta com arquivo problemático do repositório para algum outro local.
2. Certificar-se .svn\text-base\<problematic file>.svn-base é idêntico a um verificado.
3. Certifique-se de que a seção do arquivo problemático (todas as linhas da seção) em .svn\entries é idêntico a um verificado.

Answer 15

Você não vai acreditar, mas na verdade corrigi meu erro removendo o <scm>...</scm> postura do arquivo pom.xml ofensivo que eu esperava verificar.Ele continha a URL do repositório Subversion no qual foi feito o check-in (é para isso que serve a configuração do Maven!), mas de alguma forma gerou uma soma de verificação defeituosa para o arquivo durante o check-in.

Eu literalmente tentei todos os métodos mencionados acima para consertar isso, mas sem sucesso.Encontrei uma situação muito rara em que o gerador de checksum não é robusto o suficiente?

Answer 16

Também me deparei com esse problema e estava tentando procurar soluções rápidas, tentei algumas das soluções fornecidas neste tópico.Foi assim que resolvi esse problema em meu ambiente de desenvolvimento (para mim foi uma mudança mínima):

1- Diretório excluído localmente onde o arquivo foi corrompido (WEB-INF):

 svn: Checksum mismatch for 'path-to-folder\WEB-INF\web.xml':
   expected:  d60cb051162e4a6790a3ea0c9ddfb434
     actual:  16885ded2cbc1adc250e4cbbc1427546

2- Diretório copiado e colado (WEB-INF) de um novo checkout

3- O svn foi ativado, agora o Eclipse/TortoiseSVN começou a mostrar conflito neste diretório

4- Conflito marcado como Resolvido

Isso funcionou, consegui atualizar, confirmar web.xml corrompido anteriormente

Answer 17

No meu caso a soma foi diferente.Tudo que fiz foi:

1) Faça Check Out em uma pasta separada

2) Substitua o arquivo desta pasta no diretório .svn pelo arquivo de problema do meu projeto que foi dito na mensagem de erro do svn-client

3) ..Lucro!

Answer 18

Embora este seja um problema antigo, pensei em dar meus 2 centavos também, já que lutei com o problema por mais de uma hora.

As soluções acima não funcionaram para mim ou pareciam muito complicadas.

Minha solução foi simplesmente remover todas as pastas SVN do projeto.

find . -name .svn -exec rm -rf {} \;

Depois disso, fiz o checkout simples do projeto novamente.Deixando assim todos os meus arquivos não confirmados intactos, mas ainda consegui uma reconstrução de todos os arquivos svn.

Answer 19

Eu tive esse problema no Ubuntu 14.04 e resolvi-o seguindo os passos:

1. $ cd /var/www/meuProjeto
2. atualização $ svn
3. $ atualização svn

após essas etapas eu poderia enviar o arquivo sem erros.

Answer 20

1. Vá para a pasta que está causando o problema
2. Executar comando svn update --set-depth empty
3. Esta pasta irá esvaziar e reverter a pasta vazia
4. Sincronize com o svn e atualize.

Isso funciona para mim.

Answer 21

veja como resolvi o problema - muito simples, mas conforme jsh acima, preciso ter certeza de que sua cópia é a melhor.

simplesmente

1. faça uma cópia de todos os arquivos problemáticos, na mesma pasta.
2. exclua os antigos com svn rm
3. comprometer-se.
4. em seguida, renomeie as cópias de volta aos nomes dos arquivos originais.
5. comprometer novamente.

suspeito que isso provavelmente mata todos os tipos de histórico de revisão nesse arquivo, então é uma maneira muito feia de fazer isso ...