a placa-mãe de um servidor dedicado que estou alugando há cinco anos quebrou e a placa-mãe foi substituída por uma nova. A distro muito antiga (Debian) não conseguia acompanhar todo o novo hardware da placa-mãe então decidi reinstalar uma nova distro (Debian Wheezy) do zero (mesmo fazer uma atualização era meio problemático visto que o antigo Debian não Não reconheço o chipset Ethernet da nova placa-mãe, pelo que sei, então fiz uma reinstalação do zero).
Reinstalei o SVN e obtive todos os repositórios fazendo:
tar -xzf repoBackups.tgz
E "funciona".
O problema é que embora, digamos, o Eclipse reconheça os repositórios SVN, ele deseja submeter cada arquivo, mesmo que sejam idênticos.
Isso poderia estar relacionado aos carimbos de data e hora nos arquivos? De qualquer forma, você tem alguma ideia do que causou isso e como resolver o problema?
EUpoderiasimplesmente peça a todos para submeter novamente cada arquivo de cada projeto e acho que tudo ficaria bem, mas alguns desses projetos são muito grandes e seriam um pouco dolorosos para os desenvolvedores.
Como pergunta bônus (e menos importante): outro VCS como Git ou Mercurial não "sofreria" com esse problema?
Responder1
Copiar os arquivos de um repositório Subversion não é uma forma suportada de fazer backup dele. (Ver[SVN]: Como fazer backup do repositório?equal é a melhor maneira de fazer backup de repositórios do Subversion?eComo faço backup de um repositório SVN remotopara métodos adequados.) Parece que o banco de dados acabou corrompido.
Tente executar svnadmin dumpno repositório não tarado e svnadmin loadno dump resultante. Isso pode resultar em um repositório funcional (mas sem promessas, não estou muito familiarizado com o svn).
Os carimbos de data/hora nos arquivos são irrelevantes. O Subversion não os utiliza para decidir se deseja submeter, ele utiliza números de revisão.