subversion - git-svn workflow para combinar utilizando svn.pushmergeinfo

migrate svn to git with branches

Question

¿Cuál es el flujo de trabajo correcto para fusionar ramas rastreadas svn usando git-svn? He leído un poco sobre la clave de configuración git-svn svn.pushmergeinfo, 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 intente llenar automáticamente la propiedad svn: mergeinfo en el repositorio 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 rama SVN ^ / branches / 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

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

Answer 1

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 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 rama SVN "remota" como fuente. Esto ahorra el cambio de ramas 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 cuenta 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 referencia automática de las líneas mergeinfo . Esto ha sucedido rara vez en nuestro repositorio, pero hasta ahora no me ha causado ningún problema.