{"thread":{"id":"29795","subject":"git-svn with svn.pushmergeinfo incorrectly creates self-referencing svn:mergeinfo properties","startedAt":"2012-03-01T15:05:20Z","lastAt":"2012-03-14T11:38:42Z","messageCount":2,"participants":["Avishay Lavie"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"185819","messageId":"CAHkK2bokWzhtaB9CEEG3Uths1DXHAzj7QzH0V3p0FGvE_ua2hQ@mail.gmail.com","threadId":"29795","inReplyTo":"CAHkK2bpg3AYtue=uPVXFMqkyjL5xuZNhfJ6vy-pj2T8Q88ysqg@mail.gmail.com","subject":"git-svn with svn.pushmergeinfo incorrectly creates self-referencing svn:mergeinfo properties","fromName":"Avishay Lavie","fromEmail":"some.avish@gmail.com","sentAt":"2012-03-01T15:05:20Z","receivedAt":"2012-03-01T15:05:20Z","isPatch":false,"sender":{"key":"some.avish@gmail.com","avatar":null},"body":"Hello,\n\nI'm using git-svn from git 1.7.8.msysgit.0 with svn.pushmergeinfo set.\nSo far, it works beautifully and really closes the gap for developers\nto be able to work with git-svn, including merging/reintegrating SVN\nbranches.\nHowever, there seem to be a subtle bug in git-svn's behavior, where\nthe svn:mergeinfo property on a branch references commits from the\nsame branch, effectively saying \"this branch was merged onto itself\".\nSVN then gets confused at this in subtle ways which ultimately cause\nit to fail.\n\nThe following workflow reproduces the issue:\n\n1. Work on some branch (git checkout my-branch)\n2. Merge trunk into your branch (git merge trunk && git svn dcommit)\n3. Reintegrate the branch back to trunk (git checkout master && git\nmerge my-branch && git svn dcommit)\n4. Someone else reintegrates a different branch into trunk using a\nregular SVN client (non-git).\n5. A third someone merges trunk into their branch using a regular SVN client.\n6. That third someone now tries to merge trunk into their branch\nagain, using SVN.\n\nWhat we noticed happens is the following:\n* Step #2 adds svn:mergeinfo on your branch to represent the commits\nmerged in from trunk (this is normal and desired).\n* Step #3 copies these references from the svn:mergeinfo on the merged\nbranch back into the svn:mergeinfo property on trunk, so we end up\nwith trunk's mergeinfo referencing its own commits (this is the buggy\nbehavior -- when reintegrating with SVN, this part doesn't happen).\n* In step #4, SVN detects the self-referencing mergeinfo property on\ntrunk and removes it, leaving only mergeinfo for the other branches\n(this is also desirable behavior on SVN's part, since a branch\nshouldn't include any mergeinfo references to itself).\n* In step #5, SVN tries to apply the changes made on trunk to the\ntarget branch, including the previous merge which removed some\nmergeinfo references. This removes the same trunk commits from the\nmergeinfo property on the target branch, leaving \"holes\" in mergeinfo\nproperty for trunk on that branch.\n* In step #6, SVN detects that the mergeinfo property for trunk on the\ntarget branch has holes in it, and tries to merge those revisions from\ntrunk again. This causes tree conflicts and other noise which fails\nthe merge.\n\nAs I see it, the bug here is the creation of self-referencing\nmergeinfo properties in step #3; SVN doesn't exhibit this behavior and\nthis is what causes the problems later on.\nI think a general solution is to never add an svn:mergeinfo line\nreferencing the branch being dcommitted into.\n\nCan anyone confirm this is indeed a bug, suggest a fix or workaround\nand/or point me at the relevant code?\n\nThank you,\n\nAvish\n"},{"id":"186930","messageId":"CAHkK2bqo63zk1NYSoTUZJuL4W+=n_njZOPQvr1WhuBOqk=Xk3A@mail.gmail.com","threadId":"29795","inReplyTo":"CAHkK2bokWzhtaB9CEEG3Uths1DXHAzj7QzH0V3p0FGvE_ua2hQ@mail.gmail.com","subject":"Re: git-svn with svn.pushmergeinfo incorrectly creates self-referencing svn:mergeinfo properties","fromName":"Avishay Lavie","fromEmail":"some.avish@gmail.com","sentAt":"2012-03-14T11:38:42Z","receivedAt":"2012-03-14T11:38:42Z","isPatch":false,"sender":{"key":"some.avish@gmail.com","avatar":null},"body":"Anyone? Please?\nEven a code pointer into git-svn's mergeinfo handling would be a start...\n\nAvish\n\nOn Thu, Mar 1, 2012 at 5:05 PM, Avishay Lavie <some.avish@gmail.com> wrote:\n>\n> Hello,\n>\n> I'm using git-svn from git 1.7.8.msysgit.0 with svn.pushmergeinfo set.\n> So far, it works beautifully and really closes the gap for developers\n> to be able to work with git-svn, including merging/reintegrating SVN\n> branches.\n> However, there seem to be a subtle bug in git-svn's behavior, where\n> the svn:mergeinfo property on a branch references commits from the\n> same branch, effectively saying \"this branch was merged onto itself\".\n> SVN then gets confused at this in subtle ways which ultimately cause\n> it to fail.\n>\n> The following workflow reproduces the issue:\n>\n> 1. Work on some branch (git checkout my-branch)\n> 2. Merge trunk into your branch (git merge trunk && git svn dcommit)\n> 3. Reintegrate the branch back to trunk (git checkout master && git\n> merge my-branch && git svn dcommit)\n> 4. Someone else reintegrates a different branch into trunk using a\n> regular SVN client (non-git).\n> 5. A third someone merges trunk into their branch using a regular SVN\n> client.\n> 6. That third someone now tries to merge trunk into their branch\n> again, using SVN.\n>\n> What we noticed happens is the following:\n> * Step #2 adds svn:mergeinfo on your branch to represent the commits\n> merged in from trunk (this is normal and desired).\n> * Step #3 copies these references from the svn:mergeinfo on the merged\n> branch back into the svn:mergeinfo property on trunk, so we end up\n> with trunk's mergeinfo referencing its own commits (this is the buggy\n> behavior -- when reintegrating with SVN, this part doesn't happen).\n> * In step #4, SVN detects the self-referencing mergeinfo property on\n> trunk and removes it, leaving only mergeinfo for the other branches\n> (this is also desirable behavior on SVN's part, since a branch\n> shouldn't include any mergeinfo references to itself).\n> * In step #5, SVN tries to apply the changes made on trunk to the\n> target branch, including the previous merge which removed some\n> mergeinfo references. This removes the same trunk commits from the\n> mergeinfo property on the target branch, leaving \"holes\" in mergeinfo\n> property for trunk on that branch.\n> * In step #6, SVN detects that the mergeinfo property for trunk on the\n> target branch has holes in it, and tries to merge those revisions from\n> trunk again. This causes tree conflicts and other noise which fails\n> the merge.\n>\n> As I see it, the bug here is the creation of self-referencing\n> mergeinfo properties in step #3; SVN doesn't exhibit this behavior and\n> this is what causes the problems later on.\n> I think a general solution is to never add an svn:mergeinfo line\n> referencing the branch being dcommitted into.\n>\n> Can anyone confirm this is indeed a bug, suggest a fix or workaround\n> and/or point me at the relevant code?\n>\n> Thank you,\n>\n> Avish\n"}]}