git-svn workflow para combinar utilizando svn.pushmergeinfo

¿Cuál es el flujo de trabajo correcto para fusionar twigs rastreadas svn usando git-svn? He leído un poco sobre la key de configuration git-svn svn.pushmergeinfo, y las advertencias son:

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

key de configuration: svn.pushmergeinfo

Esta opción hará que git-svn intente llenar automáticamente la propiedad svn: mergeinfo en el repository SVN cuando sea posible. Actualmente, esto solo se puede hacer cuando se realizan fusiones no rápidas donde todos los padres, excepto el primero, ya han sido insertados en SVN.

Entonces mi flujo de trabajo normal es:

Suponiendo que tengo una twig SVN ^ / branches / feature_branch

# Ensure git-svn is configunetworking 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 

Entonces para fusionar ^ / trunk en mi local_feature_branch, ¿supongo que hago algo así?

 # 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 

Usar fusionar –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 un compromiso posterior no creará ninguna mergeinfo.

Sé que los hilos (en su mayoría más antiguos) aquí en stackoverflow sugieren el uso de –squash, pero creo que en gran medida es una reliquia del pasado. He estado usando git-svn para gestionar los repos svn de nuestra empresa 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, para estar a salvo, no tengo compromisos locales no sincronizados:

 # On local_feature_branch # Update from SVN git svn fetch && git svn rebase -l # push pending commits git svn dcommit 

Luego hago una fusión 'real', usando la twig SVN "remota" como fuente. Esto ahorra el cambio de twigs y la actualización, y asegura que la bifurcación entrante no tenga ningún commit unsynced local:

 # 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 registra correctamente en la historia local, por lo que las fusiones posteriores no tendrán que lidiar con conflictos resueltos previamente. Con –squash te reunirías de nuevo con cada fusión.

Sin embargo, tenga en count que existe un problema abierto con mergeinfo cuando se fusiona de local_feature_branch a trunk (es decir, se reintegra en svn-speak): Git-SVN con svn.pushmergeinfo: cómo evitar la reference automática de las líneas mergeinfo . Esto ha sucedido rara vez en nuestro repository, pero hasta ahora no me ha causado ningún problema.