# git-svn with svn.pushmergeinfo incorrectly creates self-referencing svn:mergeinfo properties 2 messages from 2012-03-01 to 2012-03-14. Participants: Avishay Lavie. Thread: https://gitlist.dev/t/29795 ## Avishay Lavie, 2012-03-01 15:05 Subject: git-svn with svn.pushmergeinfo incorrectly creates self-referencing svn:mergeinfo properties Message-ID: URL: https://gitlist.dev/e/CAHkK2bokWzhtaB9CEEG3Uths1DXHAzj7QzH0V3p0FGvE_ua2hQ%40mail.gmail.com In-Reply-To: ``` Hello, I'm using git-svn from git 1.7.8.msysgit.0 with svn.pushmergeinfo set. So far, it works beautifully and really closes the gap for developers to be able to work with git-svn, including merging/reintegrating SVN branches. However, there seem to be a subtle bug in git-svn's behavior, where the svn:mergeinfo property on a branch references commits from the same branch, effectively saying "this branch was merged onto itself". SVN then gets confused at this in subtle ways which ultimately cause it to fail. The following workflow reproduces the issue: 1. Work on some branch (git checkout my-branch) 2. Merge trunk into your branch (git merge trunk && git svn dcommit) 3. Reintegrate the branch back to trunk (git checkout master && git merge my-branch && git svn dcommit) 4. Someone else reintegrates a different branch into trunk using a regular SVN client (non-git). 5. A third someone merges trunk into their branch using a regular SVN client. 6. That third someone now tries to merge trunk into their branch again, using SVN. What we noticed happens is the following: * Step #2 adds svn:mergeinfo on your branch to represent the commits merged in from trunk (this is normal and desired). * Step #3 copies these references from the svn:mergeinfo on the merged branch back into the svn:mergeinfo property on trunk, so we end up with trunk's mergeinfo referencing its own commits (this is the buggy behavior -- when reintegrating with SVN, this part doesn't happen). * In step #4, SVN detects the self-referencing mergeinfo property on trunk and removes it, leaving only mergeinfo for the other branches (this is also desirable behavior on SVN's part, since a branch shouldn't include any mergeinfo references to itself). * In step #5, SVN tries to apply the changes made on trunk to the target branch, including the previous merge which removed some mergeinfo references. This removes the same trunk commits from the mergeinfo property on the target branch, leaving "holes" in mergeinfo property for trunk on that branch. * In step #6, SVN detects that the mergeinfo property for trunk on the target branch has holes in it, and tries to merge those revisions from trunk again. This causes tree conflicts and other noise which fails the merge. As I see it, the bug here is the creation of self-referencing mergeinfo properties in step #3; SVN doesn't exhibit this behavior and this is what causes the problems later on. I think a general solution is to never add an svn:mergeinfo line referencing the branch being dcommitted into. Can anyone confirm this is indeed a bug, suggest a fix or workaround and/or point me at the relevant code? Thank you, Avish ``` ## Avishay Lavie, 2012-03-14 11:38 Subject: Re: git-svn with svn.pushmergeinfo incorrectly creates self-referencing svn:mergeinfo properties Message-ID: URL: https://gitlist.dev/e/CAHkK2bqo63zk1NYSoTUZJuL4W%2B%3Dn_njZOPQvr1WhuBOqk%3DXk3A%40mail.gmail.com In-Reply-To: ``` Anyone? Please? Even a code pointer into git-svn's mergeinfo handling would be a start... Avish On Thu, Mar 1, 2012 at 5:05 PM, Avishay Lavie wrote: > > Hello, > > I'm using git-svn from git 1.7.8.msysgit.0 with svn.pushmergeinfo set. > So far, it works beautifully and really closes the gap for developers > to be able to work with git-svn, including merging/reintegrating SVN > branches. > However, there seem to be a subtle bug in git-svn's behavior, where > the svn:mergeinfo property on a branch references commits from the > same branch, effectively saying "this branch was merged onto itself". > SVN then gets confused at this in subtle ways which ultimately cause > it to fail. > > The following workflow reproduces the issue: > > 1. Work on some branch (git checkout my-branch) > 2. Merge trunk into your branch (git merge trunk && git svn dcommit) > 3. Reintegrate the branch back to trunk (git checkout master && git > merge my-branch && git svn dcommit) > 4. Someone else reintegrates a different branch into trunk using a > regular SVN client (non-git). > 5. A third someone merges trunk into their branch using a regular SVN > client. > 6. That third someone now tries to merge trunk into their branch > again, using SVN. > > What we noticed happens is the following: > * Step #2 adds svn:mergeinfo on your branch to represent the commits > merged in from trunk (this is normal and desired). > * Step #3 copies these references from the svn:mergeinfo on the merged > branch back into the svn:mergeinfo property on trunk, so we end up > with trunk's mergeinfo referencing its own commits (this is the buggy > behavior -- when reintegrating with SVN, this part doesn't happen). > * In step #4, SVN detects the self-referencing mergeinfo property on > trunk and removes it, leaving only mergeinfo for the other branches > (this is also desirable behavior on SVN's part, since a branch > shouldn't include any mergeinfo references to itself). > * In step #5, SVN tries to apply the changes made on trunk to the > target branch, including the previous merge which removed some > mergeinfo references. This removes the same trunk commits from the > mergeinfo property on the target branch, leaving "holes" in mergeinfo > property for trunk on that branch. > * In step #6, SVN detects that the mergeinfo property for trunk on the > target branch has holes in it, and tries to merge those revisions from > trunk again. This causes tree conflicts and other noise which fails > the merge. > > As I see it, the bug here is the creation of self-referencing > mergeinfo properties in step #3; SVN doesn't exhibit this behavior and > this is what causes the problems later on. > I think a general solution is to never add an svn:mergeinfo line > referencing the branch being dcommitted into. > > Can anyone confirm this is indeed a bug, suggest a fix or workaround > and/or point me at the relevant code? > > Thank you, > > Avish ```