Przepływ pracy git-svn do łączenia za pomocą svn.pushmergeinfo

Question

Jaki jest prawidłowy przepływ pracy dla łączenia gałęzi śledzonych svn za pomocą git-svn. Czytałem trochę o git-svn svn.pushmergeinfo klucza config, a zastrzeżenia to:

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

klucz config: svn.pushmergeinfo

Ta opcja spowoduje git -svn na spróbuje automatycznie wypełnić właściwość svn: mergeinfo w repozytorium SVN , jeśli to możliwe. Obecnie można to zrobić tylko wtedy, gdy dcommitting non-fast-forward łączy się, gdy wszyscy rodzice, ale pierwszy zostały już przekazane do SVN.

Więc mój normalny przepływ pracy jest:

Zakładając Mam SVN Branch ^/oddziały/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 

Następnie scalić się ^/trunk do mojego local_feature_branch Zakładam zrobić coś jak ?

# 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

Korzystanie seryjnej --squash i svn.pushmergeinfo razem nie ma większego sensu. W wyniku scalenia --squash wynikowe zatwierdzenie nie będzie wiązaniem scalającym, więc kolejne polecenie dcommit nie utworzy żadnych informacji mergeinfo.

Wiem, że (głównie starsze) wątki tutaj na stackoverflow sugerują użycie --squash, ale myślę, że to w dużej mierze relikt przeszłości. Używam git-svn do zarządzania repozytoriami svn naszej firmy przez blisko rok i do tej pory działało świetnie w następującym przepływie pracy:

Zawsze upewniam się przed połączeniem, że jestem na bieżąco i, dla pewności, że nie mam żadnych lokalnych niezsynchronizowane zobowiązuje:

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

# push pending commits 
git svn dcommit 

Potem zrobić „prawdziwe” łączyć, za pomocą „pilota” SVN oddziału jako źródła. Oszczędza przełączania oddziałów i aktualizacji, i zapewnia, że ​​oddział przychodząca nie ma żadnych lokalnych niezsynchronizowane zobowiązuje:

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

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

Również ten sposób scalania zostanie poprawnie zarejestrowane w lokalnej historii, więc kolejne scala nie będzie miał radzić sobie z wcześniej rozwiązanymi konfliktami. Dzięki --squash możesz ponownie je sprawdzać przy każdym scaleniu.

Należy jednak zauważyć, że istnieje otwarty problem z mergeinfo podczas łączenia z local_feature_branch do trunk (tj. Reintegrate in svn-speak): Git-SVN with svn.pushmergeinfo: how to avoid self-referencing mergeinfo lines. Zdarzyło się to rzadko w naszym repozytorium, ale jak dotąd nie sprawiało mi to kłopotu.