Re: [PATCH 2/2] git-svn: only look at the root path for svn:mergeinfo

From: Jakob Stoklund Olesen <stoklund@2pi.dk>
Date: Apr 27, 2014, 19:00 UTC
Message-ID: <7C3E8DB5-4E0D-48B4-B5B6-3EE268AE639F@2pi.dk>
In-Reply-To: <20140422185459.GA17248@dcvr.yhbt.net>

On Apr 22, 2014, at 11:54 AM, Eric Wong <normalperson@yhbt.net> wrote:

Show 6 quoted lines

> Jakob Stoklund Olesen <stoklund@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.

Show 7 quoted lines

> 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