{"thread":{"id":"21782","subject":"Re: git-svn: SVK merge commits can have >2 parents","startedAt":"2009-11-29T07:28:39Z","lastAt":"2009-11-29T20:47:13Z","messageCount":5,"participants":["Alex Vandiver","Eric Wong","Sam Vilain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"128669","messageId":"1259479636-sup-573@utwig","threadId":"21782","inReplyTo":null,"subject":"git-svn: SVK merge commits can have >2 parents","fromName":"Alex Vandiver","fromEmail":"alex@chmrr.net","sentAt":"2009-11-29T07:28:39Z","receivedAt":"2009-11-29T07:28:39Z","isPatch":false,"sender":{"key":"alex@chmrr.net","avatar":"https://avatars.githubusercontent.com/u/28347?v=4"},"body":" Heya,\n\nWhile converting a mildly complicated svn repository that was managed\nwith SVK, I ran across the following oddness. `svk smerge` can only\nmerge between _two_ branches at once -- however, the way that svk\nmerge detection works, you can end up with erroneous extra parents\nfrom long-dead branches. Case in point:\n\n export SVKROOT=/tmp/svk-testing-$$\n svk mkdir //trunk -m 'trunk'\n svk mkdir //branches -m 'branches'\n svk co //trunk\n svk cp //trunk/ //branches/feature1 -m 'branch for feature1'\n svk cp //trunk/ //branches/feature2 -m 'branch for feature2'\n svk co //branches/feature1\n cd feature1\n echo \"foo\" >foo\n svk add foo\n svk ci -m 'feature1 development'\n svk sm //branches/feature1 //trunk -m 'merge feature1 to trunk'\n cd ..\n svk co //branches/feature2\n cd feature2\n echo \"bar\" >bar\n svk add bar\n svk ci -m 'feature2 development'\n svk sm //trunk //branches/feature2 -m 'merge from trunk'\n cd ..\n\n git svn clone -s file://$SVKROOT/local\n\nThe 'feature2' branch will appear to have three parents: r7, r6, _and_\nr5. The r5 parent is extraneous, and only appears because r5 was\npreviously merged into trunk, as part of r6.\n\nGiven this, I'm a little confused why find_extra_svk_parents is\nwritten the way that it is, in seemingly allowing multiple extra\nparents to be found. Since the most recent (i.e., highest-numbered)\nchange is by definition the only one that can account for all of the\nother svk:merge changes, I _believe_ the attached diff to be correct,\nbut I'm unsure because of the implicit current assumption that smerges\ncan produce multiple parents.\n\n - Alex\n-- \nNetworking -- only one letter away from not working\n\n\nFrom b86b4bb0cecb70d828558b046aa0b3e7b899bf41 Mon Sep 17 00:00:00 2001\nFrom: Alex Vandiver \nDate: Sun, 29 Nov 2009 02:20:21 -0500\nSubject: [PATCH] git-svn: svk merge commits should only add one exta parent\n\nWhen merging branches based on svk:merge properties, a single merge\ncan have updated or added multiple svk:merge lines. If so. only\ninclude the minimal set of new parents.\n\nSigned-off-by: Alex Vandiver \n---\n git-svn.perl | 5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 957d44e..668e50c 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -2940,10 +2940,12 @@ sub find_extra_svk_parents {\n \t\t\tif ( my $commit = $gs->rev_map_get($rev, $uuid) ) {\n \t\t\t\t# wahey! we found it, but it might be\n \t\t\t\t# an old one (!)\n-\t\t\t\tpush @known_parents, $commit;\n+\t\t\t\tpush @known_parents, [ $rev, $commit ];\n \t\t\t}\n \t\t}\n \t}\n+\t# We only care about the highest-numbered applicable commit\n+\t@known_parents = map {$_->[1]} sort {$b->[0] <=> $a->[0]} @known_parents;\n \tfor my $parent ( @known_parents ) {\n \t\tmy @cmd = ('rev-list', $parent, map { \"^$_\" } @$parents );\n \t\tmy ($msg_fh, $ctx) = command_output_pipe(@cmd);\n@@ -2956,6 +2958,7 @@ sub find_extra_svk_parents {\n \t\t\tprint STDERR\n \t\t\t \"Found merge parent (svk:merge ticket): $parent\\n\";\n \t\t\tpush @$parents, $parent;\n+\t\t\treturn;\n \t\t}\n \t}\n }\n-- \n1.6.6.rc0.254.g7352d\n\n"},{"id":"128668","messageId":"1259480367-sup-6891@utwig","threadId":"21782","inReplyTo":"1259479636-sup-573@utwig","subject":"Re: git-svn: SVK merge commits can have >2 parents","fromName":"Alex Vandiver","fromEmail":"alex@chmrr.net","sentAt":"2009-11-29T07:46:49Z","receivedAt":"2009-11-29T07:46:49Z","isPatch":false,"sender":{"key":"alex@chmrr.net","avatar":"https://avatars.githubusercontent.com/u/28347?v=4"},"body":"At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:\n> While converting a mildly complicated svn repository that was managed\n> with SVK, I ran across the following oddness. `svk smerge` can only\n> merge between _two_ branches at once -- however, the way that svk\n> merge detection works, you can end up with erroneous extra parents\n> from long-dead branches.\n\nUpon a little more inspection, I now understand that the rev-parse\nlines in find_extra_svk_parents are attempting to deal with this exact\ncircumstance -- but they fail to properly sort the merge tickets\nfirst, which leads to this incorrect behavior. Armed with this\nunderstanding, I'm more confident in the attached updated patch. I\nassume, however, that the logic allows for more than one extra parent\nonly because such an occurrance could be constructed by hand-editing\nsvk:merge, because AFAIK svk's command-line tools should be able to\nconstruct such a circumstance.\n - Alex\n-- \nNetworking -- only one letter away from not working\n\n\nFrom 4d30e57e5da7c2e880908bc742cf80990d6f9f5d Mon Sep 17 00:00:00 2001\nFrom: Alex Vandiver \nDate: Sun, 29 Nov 2009 02:20:21 -0500\nSubject: [PATCH] git-svn: sort svk merge tickets to account for minimal parents\n\nWhen merging branches based on svk:merge properties, a single merge\ncan have updated or added multiple svk:merge lines. Attempt to\ninclude the minimal set of parents by sorting the merge properties in\norder of revision, highest to lowest.\n\nSigned-off-by: Alex Vandiver \n---\n git-svn.perl | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 957d44e..51f03ad 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -2940,10 +2940,14 @@ sub find_extra_svk_parents {\n \t\t\tif ( my $commit = $gs->rev_map_get($rev, $uuid) ) {\n \t\t\t\t# wahey! we found it, but it might be\n \t\t\t\t# an old one (!)\n-\t\t\t\tpush @known_parents, $commit;\n+\t\t\t\tpush @known_parents, [ $rev, $commit ];\n \t\t\t}\n \t\t}\n \t}\n+\t# Ordering matters; highest-numbered commit merge tickets\n+\t# first, as they may account for later merge ticket additions\n+\t# or changes.\n+\t@known_parents = map {$_->[1]} sort {$b->[0] <=> $a->[0]} @known_parents;\n \tfor my $parent ( @known_parents ) {\n \t\tmy @cmd = ('rev-list', $parent, map { \"^$_\" } @$parents );\n \t\tmy ($msg_fh, $ctx) = command_output_pipe(@cmd);\n-- \n1.6.6.rc0.254.g7352d\n\n"},{"id":"128670","messageId":"20091129080815.GC24222@dcvr.yhbt.net","threadId":"21782","inReplyTo":"1259480367-sup-6891@utwig","subject":"Re: git-svn: SVK merge commits can have >2 parents","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-11-29T08:08:16Z","receivedAt":"2009-11-29T08:08:16Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Alex Vandiver wrote:\n> At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:\n> > While converting a mildly complicated svn repository that was managed\n> > with SVK, I ran across the following oddness. `svk smerge` can only\n> > merge between _two_ branches at once -- however, the way that svk\n> > merge detection works, you can end up with erroneous extra parents\n> > from long-dead branches.\n> \n> Upon a little more inspection, I now understand that the rev-parse\n> lines in find_extra_svk_parents are attempting to deal with this exact\n> circumstance -- but they fail to properly sort the merge tickets\n> first, which leads to this incorrect behavior. Armed with this\n> understanding, I'm more confident in the attached updated patch. I\n\nHi Alex, Sam,\n\nI'll defer to Sam for the Ack, my svk knowledge is limited. Thanks.\n\n-- \nEric Wong\n"},{"id":"128679","messageId":"1259493967.31767.4.camel@denix","threadId":"21782","inReplyTo":"20091129080815.GC24222@dcvr.yhbt.net","subject":"Re: [spf:guess] Re: git-svn: SVK merge commits can have >2 parents","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-11-29T11:26:07Z","receivedAt":"2009-11-29T11:26:07Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Sun, 2009-11-29 at 08:08 +0000, Eric Wong wrote:\n> Alex Vandiver wrote:\n> > At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:\n> > > While converting a mildly complicated svn repository that was managed\n> > > with SVK, I ran across the following oddness. `svk smerge` can only\n> > > merge between _two_ branches at once -- however, the way that svk\n> > > merge detection works, you can end up with erroneous extra parents\n> > > from long-dead branches.\n> > \n> > Upon a little more inspection, I now understand that the rev-parse\n> > lines in find_extra_svk_parents are attempting to deal with this exact\n> > circumstance -- but they fail to properly sort the merge tickets\n> > first, which leads to this incorrect behavior. Armed with this\n> > understanding, I'm more confident in the attached updated patch. I\n> \n> Hi Alex, Sam,\n> \n> I'll defer to Sam for the Ack, my svk knowledge is limited. Thanks.\n\nYes, the change does make sense to me - nicely done, Alex.\n\nAcked-By: Sam Vilain \n\nSam\n"},{"id":"128705","messageId":"20091129204713.GA3944@dcvr.yhbt.net","threadId":"21782","inReplyTo":"1259493967.31767.4.camel@denix","subject":"Re: [spf:guess] Re: git-svn: SVK merge commits can have >2 parents","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-11-29T20:47:13Z","receivedAt":"2009-11-29T20:47:13Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Sam Vilain wrote:\n> On Sun, 2009-11-29 at 08:08 +0000, Eric Wong wrote:\n> > Alex Vandiver wrote:\n> > > At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:\n> > > > While converting a mildly complicated svn repository that was managed\n> > > > with SVK, I ran across the following oddness. `svk smerge` can only\n> > > > merge between _two_ branches at once -- however, the way that svk\n> > > > merge detection works, you can end up with erroneous extra parents\n> > > > from long-dead branches.\n> > > \n> > > Upon a little more inspection, I now understand that the rev-parse\n> > > lines in find_extra_svk_parents are attempting to deal with this exact\n> > > circumstance -- but they fail to properly sort the merge tickets\n> > > first, which leads to this incorrect behavior. Armed with this\n> > > understanding, I'm more confident in the attached updated patch. I\n> > \n> > Hi Alex, Sam,\n> > \n> > I'll defer to Sam for the Ack, my svk knowledge is limited. Thanks.\n> \n> Yes, the change does make sense to me - nicely done, Alex.\n> \n> Acked-By: Sam Vilain \n\nThanks Sam, acked and pushed to git://git.bogomips.org/git-svn\n\n-- \nEric Wong\n"}]}