Início > Pragmática > Processo de Merge Utilizando Svnmerge.py

Processo de Merge Utilizando Svnmerge.py

O Svnmerge.py é uma ferramenta para gerenciamento automático de branches. Ela facilita o processo de merge quando trabalhamos com o Subversion. Compilei a sequência de passos que sigo para melhor utilizar essa ferramenta em meu processo de merge.

1. Inicializar o merge tracking

O Merge tracking support é a “lembrança” de que revisões já foram compatibilizadas. Inicializar um merge tracking significa bloquear um intervalo de revisões que não se quer que venham no merge.

Esse passo não é necessário se o merge tracking já foi iniciado em algum momento. O merge tracking só precisa ser iniciado uma vez:

svnmerge init [BRANCH_PATH] -F

O subcomando (F) server para forçar o início do merge tracking caso este já tenha sido iniciado.

Exemplo:

svnmerge init https://svn.repository.com/project/trunk -r1-1000000 -F

1.1. Versionamento do metadado do início do merge tracking

Para serem efetivadas, as informações do merge devem ser versionadas:

svn ci -F svnmerge-commit-message.txt

Onde:

ci: Commit (Versionamento das alterações)
F: Indica que os metadados do commit virão de um arquivo
O arquivo “svnmerge-commit-message.txt” contém as informações sobre o merge. No caso do subcomando “init”, serão as informações de merge tracking. No caso do subcomando “merge”, que será explicado adiante, o arquivo conterá as revisões integradas e uma referência para a URL do branch de origem.

2. Identificar e analisar o intervalo de revisões que serão compatiblizadas com o branch de destino

Deve-se verificar as revisões disponíveis no branch que se quer compatibilizar e gerar o Release Notes.

2.1 Verificar revisões disponíveis

Caso o merge tracking já tenha sido iniciado (passo 1), o comando abaixo exibirá todas as revisões disponíveis:

svnmerge avail

Caso o merge tracking tenha sido iniciado para mais de um branch, o comando acima exibirá todos os branches disponíveis. Para exibir as revisões disponíveis de um desses branches, execute o comando:

svnmerge avail [BRANCH_PATH]

Exemplo:

svnmerge avail project/trunk

Como saber quais, dentre as revisões disponíveis, fazem parte de uma versão no branch de origem? Basta considerar apenas as revisões cujo número seja menor ou igual ao último commit de uma tag no branch de origem.

2.2. Gerar release notes

Os comandos anteriores exibem todas as revisões disponíveis para compatibilização, mas antes de iniciar os procedimento de merge, é necessário analisar cada revisão que entrará na versão. O subcomando “avail” pode ser utilizado para gerar o release notes:

svnmerge avail --log -r[REV_1...REV_N] >> release_notes.txt

O subcomando “log” gera informações mais detalhadas da revisão. Redirecionamos a saída para o arquivo .txt por praticidade. O conteúdo do arquivo fica assim:

------------------------------------------------------------------------
r111111 | userlogin | 2013-01-01 12:00:00 -0300 (Mon, 01 Jan 2013) | 1 line
Changed paths:
   M /project/trunk/src/com/ModifiedClass.java
   D /project/trunk/src/com/DeletedCLass.java
   A /project/trunk/src/com/AddedClass.properties
[COMMIT-100000] Merge test

Onde:

r111111: número da revisão
userlogin: usuário que fez o commit
2013-01-01 12:00:00 -0300: data e hora do commit
M {NOME_DO_ARQUIVO}: arquivo modificado
D {NOME_DO_ARQUIVO}: arquivo removido
A {NOME_DO_ARQUIVO}: arquivo adicionado

3. Bloqueio de revisões

As revisões que não entrarão na versão após a análise do release notes devem ser bloqueadas para facilitar o merge:

svnmerge block -r[REV_1,REV_2...REV_N]

É possível reverter um bloqueio de revisões:

svnmerge unblock -r[REV_1,REV_2...REV_N]

3.1. Versionamento do metadado do bloqueio de revisões

Para serem efetivadas, as informações do merge devem ser versionadas:

svn ci -F svnmerge-commit-message.txt

4. Merge automático

É o merge feito pela ferramenta através do comando abaixo:

svnmerge merge -b -r[REV_1...REV_N]

O svnmerge tenta fazer o merge, mas caso o arquivo que receberá as alterações também tenha sido alterado, será gerado um conflito entre as revisões. A notação dos arquivos alterados após a execução do subcomando “merge” é um pouco diferente do subcomando “avail log”:

--- Merging r324893 through r324897 into ’.’:
  C /project/trunk/src/com/TreeConflictClass.java
C   /project/trunk/src/com/ConflictClass.java
U   /project/trunk/src/com/Updated.java
D   /project/trunk/src/com/DeletedClass.java
A   /project/trunk/src/com/resources/added.properties
Summary of conflicts:
  Text conflicts: 1
  Tree conflicts: 1


Onde:
U {NOME_DO_ARQUIVO}: arquivo modificado
D {NOME_DO_ARQUIVO}: arquivo removido
A {NOME_DO_ARQUIVO}: arquivo adicionado
C {NOME_DO_ARQUIVO}: arquivo com conflito
C {NOME_DO_ARQUIVO}: arquivo com conflito de árvore. Os conflitos de árvore ocorrem quando um arquivo modificado no branch de origem do merge foi removido no branch de destino ou quando um arquivo com o mesmo nome é criado no branch de origem em uma revisão posterior a do branch de destino.

Quando ocorre conflito, sua estrutura fica como abaixo para cada linha onde houve alteração no arquivo nos dois branches compatibilizados:

<<<<<<< .working
# Código modificado no arquivo de destino
=======
# Código modificado no arquivo de origem na revisão 100000
>>>>>>> .merge-right.r100000

Basta comparar cada ponto de conflito e decidir o código que permanecerá no arquivo de destino. Remova as anotações de conflito.

5. Merge manual

Merge manual consiste em adaptar, manualmente, duas estruturas parcial ou bastante diferentes. O merge manual pode ser feito como complemento ou contingência do merge automático ou não precisa ter quaisquer relações com o merge automático, pois um merge pode ser totalmente manual. Siga os passos abaixo para fazer esse merge:

5.1. Execute o comando de merge (passo (4)). Esse passo é opcional

5.2. Descarte o arquivo mergeado e tome como base o arquivo do branch de destino

5.3. Com o auxílio de uma ferramenta de “diff”, compare a última revisão do arquivo modificado no branch de origem com a revisão anterior ao range que está sendo compatibilizado. Por exemplo, se estamos compatibilizando da revisão 1000 até a revisão 2000 e o arquivo foi modificado na revisão 1500, deve-se comparar a revisão 1500 com uma revisão anterior à revisão 1000

5.4. Julgue, linha a linha, as alterações feitas no branch de origem e traga-as para o branch de destino. Frequentemente, é necessário fazer alterações no arquivo do branch de destino para comportar as diferenças estruturais, mais não caia no erro de fazer refactorings e reescrita de código durante o merge. Merge é apenas compatibilização. Alterações maiores de código devem ser feitas no branch de desenvolvimento

6. Teste do merge

Para assegurar que o merge não introduziu bugs, são necessários dois conjuntos de testes:

6.1. Teste da fumaça

6.2. Reteste de cada funcionalidade alterada ou implementada no branch de origem. O ideal é acionar a equipe de testes para auxiliar os testes de regressão.

7. Versionamento do merge

Terminado o merge, rode o comando abaixo para resolver os conflitos:

svn resolve . -R --accept=working

O parâmetro “accept=working” indica que a sua pasta local contém a versão correta dos arquivos que serão comitados, cujos conflitos já foram resolvidos. Em seguida, rode o comando abaixo para versionar as alterações:

svn ci -F svnmerge-commit-message.txt

Obs.: Também é possível resolver os conflitos com o comando deprecated:

svn resolved . -R 

Dica

Quando o conteúdo dos branches difere a ponto de o svnmerge não ser capaz de fazer merge e nem indicar pontos específicos de conflito (ele indica que a classe inteira é um conflito) para dezenas de classes o mais indicado é reduzir o escopo do merge. Em casos extremos, faça a compatibilização de apenas uma ou duas revisões por vez.

Cuidado com os arquivos de texto! Arquivos .xml e .properties não acusam falha de compilação. Deve-se fazer o merge manual desses arquivos.

Resumo de Comandos

svnmerge init [BRANCH_PATH] -F            # Init forçado do merge tracking para [BRANCH_PATH]
svnmerge avail                            # Revisões disponíveis
svnmerge avail [BRANCH_PATH]              # Revisões disponíveis em [BRANCH_PATH]
svnmerge avail --log &gt;&gt; release_notes.txt # Geração do Release Notes no arquivo "release_notes.txt"
svnmerge block -r[REV_1,REV_2...REV_N]    # Bloqueio de revisões
svnmerge unblock -r[REV_1,REV_2...REV_N]  # Desbloqueio de revisões
svnmerge merge -b -r[REV_1...REV_N]       # Merge automático da revisão [REV_1] até [REV_N]
svn ci -F svnmerge-commit-message.txt     # Versionamento do merge
svn resolve . -R --accept=working         # Indica que os conflitos nos arquivos estão resolvidos
svn status                                # Checar o status de cada arquivo da sua pasta local
svn log -r HEAD                           # Loga os commits que fizeram depois do update
svn diff arquivo1@100 arquivo@200         # Diff do arquivo1 na revisão 100 com arquivo2 na revisão 200
Anúncios
Categorias:Pragmática Tags:, ,
  1. Nenhum comentário ainda.
  1. 12/02/2016 às 9:37 PM

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: