Re: Efficiency and correctness patches for git-svn mergeinfo support

[Andrew Myrick <amyrick@gmail.com>]

On Sun, Dec 20, 2009 at 1:07 PM, Sam Vilain <sam@vilain.net> wrote:
> On Sat, 2009-12-19 at 14:15 -0800, Andrew Myrick wrote:
>> I tried cloning from a fairly recent revision that I knew was after
>> our switchover to svn 1.5, and I received a number of these errors:
>>
>>    Couldn't find revmap for [branch]
>>    Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
>>    Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
>>    Exiting subroutine via next at /Users/adm/libexec/git-core/git-svn line 2983.
>>
>> I'm not sure if this is expected, since I didn't clone from the whole
>> repo, but it did cause a lot of spew.  I'm starting a fresh clone now,
>> but it takes a few days to get through the whole repository.  I'm
>> fairly new to git, so I would welcome any tips on how I can test this
>> more quickly.
>
> Whoops, no, not expected, I'll post a minor correction.  That means that
> the branch which was merged in does not have git-svn metadata; ie, it's
> not being tracked explicitly.  If people are doing merging of things
> which aren't roots of branches you would expect this.  SVN, like
> Perforce, supports a confusing amount of flexibility in its merge
> tracking.  If [branch] is a real branch, then you'll want to see why it
> doesn't have metadata yet.  Is it really a sub-tree of a real branch?
> You could fetch it independently using a separate git-svn remote, or you
> could ignore the warning; it should be relatively self-evident what
> happened from the merge message and the contents of the changeset.

I think the problem is that I started fetching from a later revision
than when the branch was created and reintegrated.  There would be no
metadata for the branch, so a lookup for it would fail.  Fetching the
branch explicitly, or fetching from r1 as my current test is doing,
should not experience this problem.

> Note if your repository was significantly re-organized at any point, it
> will pay to treat each section of history as a separate import project,
> and stitch the results together afterwards using grafts and
> filter-branch.

I don't believe it was, but I will keep that in mind if I run into
trouble.  The import from r1 went fine with git v1.6.5.*, and it's
proceeding well now.

> This version should be *significantly* faster than the old one.  ie, it
> should not take a minute per commit while importing the heavily
> merged-into integration branch.  Possibly a few seconds at most.

So far, most commits are fetched in under 3s with your new version.

Thanks for your help, Sam.

-Andrew