git-svn flujo de trabajo para fusionar usando svn.pushmergeinfo

Question

¿Cuál es el flujo de trabajo correcto para fusionar ramas rastreadas svn usando git-svn. He leído un poco sobre el git-svn svn.pushmergeinfo clave de configuración, y las advertencias son:

De http://www.kernel.org/pub/software/scm/git/docs/git-svn.html:

clave de configuración: svn.pushmergeinfo

Esta opción hará que git -svn a intento de llenar automáticamente la propiedad svn: mergeinfo en el repositorio SVN cuando sea posible. Actualmente, esto solo se puede hacer cuando commite fusiones sin avance rápido donde todos los padres pero el primer ya se han insertado en SVN.

Así que mi flujo de trabajo normal es:

Suponiendo que tengo una SVN rama ^/ramas/feature_branch

# Ensure git-svn is configured to populate svn:mergeinfo 
git config --global svn.pushmergeinfo true 

# Update my local svn remotes state 
git svn fetch 

# Track a local branch against a remote SVN backed ^/branches/feature_branch 
git checkout -b local_feature_branch remotes/feature_branch 

# Modify files and commit to local git repo 
git commit -a -m "changes" 
# Push changes to SVN branch ^/branches/feature_branch 
git svn dcommit 

Luego combinar hasta ^/tronco en mi local_feature_branch Asumo que hago algo así como ?

# Sync to the latest SVN 
git svn fetch 
# Rebase "master" which is tracking the remote SVN ^/trunk 
git checkout master 
git svn rebase 

# Checkout the local_feature_branch 
git checkout local_feature_branch 

# Merge "master" into "local_feature" which is tracking ^/trunk 
git merge --squash master 
git commit -m "merge master which is tracking SVN ^/trunk" 

# Dry run the dcommit to SVN which should include svn:mergeinfo property changes 
git svn dcommit --dry-run 

# Commit merge to trunk 
git svn dcommit 

Answer 1

Usando fusión --squash y svn.pushmergeinfo juntos no tiene mucho sentido. Con merge --squash, la confirmación resultante no será una confirmación de fusión, por lo que una dcommit subsiguiente no creará mergeinfo.

Sé que (en su mayor parte) los hilos aquí en stackoverflow sugieren el uso de --squash, pero creo que es en gran parte una reliquia del pasado. He estado usando git-svn para gestionar los repos svn de nuestra compañía durante casi un año, y hasta ahora funcionaba muy bien con el siguiente flujo de trabajo:

Siempre me aseguro antes de la fusión de que estoy actualizado y, sólo para estar seguro, que no tengo ningún commit que no estén sincronizados locales:

# On local_feature_branch 
# Update from SVN 
git svn fetch && git svn rebase -l 

# push pending commits 
git svn dcommit 

Entonces hago un 'real' se fusionan, utilizando la rama SVN "a distancia" como fuente. Esto ahorra conmutación ramas y actualización, y asegura que la rama entrante no tiene ningún commit que no estén sincronizados locales:

# Create a real, non-forward merge commit 
git merge --no-ff svn/trunk 

# ... and push it to SVN, including mergeinfo 
git svn dcommit 

Además, de esta manera la fusión se registró correctamente en la historia local, por lo que las siguientes fusiones no tendrán para tratar conflictos previamente resueltos. Con --squash te reunirías de nuevo con cada fusión.

Sin embargo, tenga en cuenta que hay un problema abierto con mergeinfo al fusionarse de local_feature_branch a trunk (es decir, una reintegración en svn-speak): Git-SVN with svn.pushmergeinfo: how to avoid self-referencing mergeinfo lines. Esto ha sucedido rara vez en nuestro repositorio, pero hasta ahora no me ha causado ningún problema.