On Apr 22, 2014, at 11:54 AM, Eric Wong normalper...@yhbt.net wrote:
Jakob Stoklund Olesen stokl...@2pi.dk wrote:
Subversion can put mergeinfo on any sub-directory to track cherry-picks.
Since cherry-picks are not represented explicitly in git, git-svn should
just ignore it.
Hi, was git-svn trying to track cherry-picks as merge before?
It would try and fail. I didn't explain that properly in the commit message.
Suppose I have a standard svn layout with $url/trunk and $url/branches/topic1.
My topic1 branch has a change in subdir1 that I want to cherry-pick into trunk:
% svn switch $url/trunk
% cd subdir1
% svn merge $url/branches/topic1/subdir1
% cd ..
% svn commit
This operation will set svn:mergeinfo on $url/trunk/subdir1 where a normal full
merge would set it on $url/trunk:
% svn pg svn:mergeinfo subdir1
/branches/topic1/subdir1:3-4
When git-svn fetches these changes, it currently does examine the svn:mergeinfo
change on the subdirectory as if it were a full merge. It then fails to find a
revmap for /branches/topic1/subdir1:
Couldn't find revmap for file:///tmp/sdb/branches/topic1/subdir1
r5 = 5ce1f687c30495deca40730fb7be3baa0e145479 (refs/remotes/trunk)
It is looking for refs/remotes/topic1/subdir1, but we only have the
refs/remotes/topic1 branch in git.
This patch makes git-svn stop trying to reconstruct those subdirectory merges
that we know will fail anyway.
This changes behavior a bit, so two independent users of git-svn
may not have identical histories as a result, correct?
For normal subdirectory cherry-picks as described above, the behavior doesn't
change. This is just a performance optimization.
For weirder cases where a whole branch has been merged onto a subdirectory of
trunk, behavior does change. Currently, git-svn will mark that as a full merge
in git. With this change it won't.
Can you add a test to ensure this behavior is preserved?
Thanks.
I'll add a test for the subdirectory merge described above.
Sorry, I've never looked at mergeinfo myself, mainly relying on
Sam + tests for this.
[1] - Historically, git-svn (using defaults) has always tried to
preserve identical histories for independent users across
different git-svn versions. However, mergeinfo may be
enough of a corner-case where we can make an exception.
I agree. It doesn't seem worthwhile to try to preserve git-svn's historical
behavior in weird corner cases.
BTW, this performance optimization matters not because of sporadic manual
cherry-picks, but because certain older svn releases would replicate
svn:mergeinfo on every subdirectory in a standard merge. With hundreds of
subdirectories and thousands of merged branches, git-svn gets completely stuck
processing all those mergeinfo lines.
Thanks,
/jakob
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
