Mantendo uma parte de um repositório Subversion, mas há uma mudança de caminho no meio

Question

Eu tenho um repositório Subversion onde um diretório foi movido uma vez. eu quero enviar para alguém apenas uma parte do repositório, que inclui este diretório.

Acredito que li e compreendi o manual .

O que eu tentei:

svnadmin dump /home/Subversion-Repository | \
   svndumpfilter include new-name /new-name /foo/bar/old-name > something.svn

svnadmin create /new/repos
# Create directories foo/bar and new-name
svnadmin load /new/repos < something.svn

Mas isso falha:

<<< Started new transaction, based on original revision 5944
svnadmin: File not found: transaction '5944-4l4', path 'new-name/myfile'
     * editing path : new-name/myfile ...

O que me surpreende é que, no lixão cheio (sem passar por svndumpfilter), há uma revisão que adiciona os arquivos ao novo lugar:

Node-path: new-name
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10

mas o svndumpfilter não o mantém. Então, a primeira revisão mencionando um arquivo sob o novo nome é 'Node-action: change' e não 'Node-action: add 'e falha. Por quê?

Um script de shell Unix para reproduzir o problema à vontade é disponível .

[Eu fiz a pergunta na lista de discussão do Subversion, mas a mensagem não foi distribuída, provavelmente consumida por um filtro de spam excessivamente zeloso.]

UPDATE: eu testei a sugestão de Insyte. Ambos svndumpfilter2 e svndumpfilter3 falha. Ambos nem sequer verificam o argumento, você pode dar um repositório inexistente, eles não se queixariam.

Com svndumpfilter2, modificando meu script para usar ${SVNDUMPFILTER2} ${REPOS} other/new-name/bar foo/old-name/bar > ${DUMP} :

<<< Started new transaction, based on original revision 7
svnadmin: File not found: transaction '8-8', path 'other/new-name/bar/myfile'
     * editing path : other/new-name/bar/myfile ...

Com svndumpfilter3, modificando meu script para usar ${SVNDUMPFILTER3} --untangle=${REPOS} other/new-name/bar foo/old-name/bar > ${DUMP} :

<<< Started new transaction, based on original revision 7
svnadmin: File not found: transaction '8-8', path '/other/new-name/bar/myfile'
     * editing path : other/new-name/bar/myfile ...

    

Answer 1

OK, eu tenho agora uma solução que funciona, testada em um real repositório. A ideia é descarregar apenas revisões até (e não incluindo) a renomeando, depois as revisões depois dele (com o --incremental opção). Então, eu recarregar o primeiro despejo, eu faço uma renomeação no novo repositório, e eu recarregar o segundo despejo. Parece funcionar corretamente.

Eu fiz uma versão modificada do meu script que mostra os detalhes passos.

Se eu entendi corretamente, o problema original era que a renomeação ocorreu em um nível superior na árvore do que os diretórios que eu queria manter e assim não foi mantido pelo svndumpfilter. Portanto, o operações em arquivos após a renomeação falhou porque os nós no despejo eram do tipo change e não havia nenhum nó do tipo add para o novo local.

    

Answer 2

Acredito que você esteja encontrando uma variante do problema svndumpfilter: Invalid copy source path . Esse problema ocorre quando um dos diretórios / arquivos incluídos pelo svndumpfilter foi originalmente copiado (ou, no seu caso, movido) de uma seção da árvore que está não sendo incluída. A solução original para isso foi a de Simon Tatham svndumpfilter2 mas seu servidor svn parece estar desativado no momento.

Uma versão ligeiramente modificada está disponível aqui: link

Outra variante aqui: link

E outro aqui: link

com explicação para svndumpfilter4 aqui (do archive.org - infelizmente o original não está mais acessível): link

As variantes são inteligentes o suficiente para usar o svnlook para recuperar o material fonte necessário, mesmo que ele viva fora da seção incluída da árvore.

    

Answer 3

Você também pode experimentar o dumpsanitizer . Ele lida com os casos de problemas nos quais os arquivos / diretórios foram movidos, sem precisar fazer isso manualmente. Usamos essa abordagem para definir parte de um repositório mais antigo como uma linha de base para um novo repositório.