o carregamento do subversion falha com “nenhuma tal revisão”

18

Estou tentando aprender como migrar um repositório do Subversion e estou me deparando com um problema que não faz sentido para mim. Usei svndumpfilter para dividir um subprojeto e removi alguns prefixos de caminho. Várias centenas de commits agora são importadas corretamente, mas estou recebendo o seguinte erro:

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/build.properties ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

OK, vou para o arquivo de despejo para ver as revisões 19190 e 19098. Em primeiro lugar, a revisão 19098 existe existe no arquivo de despejo e foi importada sem nenhum problema. Revisão 19190 é uma mesclagem. Em 19190, aqui está a informação do último arquivo, que parece estar causando o problema:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Confusamente, a revisão 19100 NÃO existe neste arquivo filtrado. Mas o erro não está se referindo a 19100, está se referindo a 19098!

O que eu faço para que esse arquivo seja carregado?

Obrigado!

    
por Harlan 28.08.2013 / 18:20

2 respostas

1

Eu fiz esse tipo de divisão muitas vezes. Eu acho que tudo depende de como você usa o filtro e o processamento que você faz no arquivo de despejo depois. Pessoalmente, eu também tive que mudar o usuário svn, ao lado do caminho do projeto, e renumerar as revisões. Só para você ver o que pode ser feito, aqui está parte relevante do meu roteiro.

grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

O que acontece lá é que primeiro, eu filtro o que preciso, deixo as revisões vazias por razões óbvias e as renumino. Isso dá ótimas revisões ordenadas. Então eu soltei o caminho da raiz do projeto que no meu caso estava na forma de grupo / cliente porque no novo repositório que não tem sentido (em vez disso o repo em si é grupo / cliente no disco) - este é o primeiro 2s

A seguir, eu removo a importação de diretórios não-nomeados, um resultante dos 2 seds acima para o diretório group e depois um para o diretório group / customer adicionando.

finalmente, seduzo o autor para alterá-lo para um novo. Este foi um pouco complicado, pois exigia a atualização do comprimento da definição da propriedade.

Depois eu carrego e corrijo as permissões do sistema de arquivos. Observe os 2 chowns comentados do apache, em alguns casos você precisará dele. Eu eventualmente acabei adicionando o apache ao grupo svn.

Agora, eu nunca tive fusões no repositório do SVN, então nunca tive que lidar com elas para a divisão. No seu caso, eu imagino que o que acontece é que o caminho da revisão de origem não é importado e é por isso que ele não o encontra mesmo que o erro seja uma reclamação da própria revisão). A regra básica no arquivo de importação do svn é que tudo o que é referido em um ponto já deve ter sido importado antes de ser referido. Então você pode ter filtrado algo que você não deveria, mesmo que você queira, ou não atualizar o arquivo de despejo corretamente para refletir quaisquer outras alterações que você tenha feito.

Se você fornecer a estrutura relevante de seu repositório original, incluindo o caminho da origem mesclado, além de suas chamadas com parâmetros, eu posso saber o que você perdeu. Meu dinheiro está na origem da fusão.

    
por 10.09.2015 / 19:45
0

Eu usei uma ótima ferramenta svndumpsanitizer . O problema é que a estrutura do repositório do subversion é muito complicada. Quando o svndumpfilter está na revisão 10, não tem como saber se um nó que o usuário deseja descartar será movido para uma posição que ele deseja manter na revisão 113. Portanto, ele faz a única coisa que pode fazer - descarta o nó e, na revisão 113, é lançado porque já descartou os dados que seriam necessários.

O Svndumpsanitizer funciona de uma maneira diferente. Ele varre os nós várias vezes para descobrir quais nós devem ser mantidos. Depois de determinar quais nós para mantê-lo, só gravamos esses nós no arquivo de saída. Finalmente - se necessário - adiciona um commit que apaga qualquer nó indesejado que tenha que ser mantido para não quebrar o repositório.

    
por 18.03.2016 / 11:33

Tags