Re: Efficiency and correctness patches for git-svn mergeinfo support
- From
- Andrew Myrick <amyrick@gmail.com>
- Date
- Dec 20, 2009, 22:03 UTC
- Message-ID
- <6b2f9b1d0912201403t4a801284j39591b2bcf6e9f93@mail.gmail.com>
- In-Reply-To
- <1261343240.20752.20.camel@denix>
On Sun, Dec 20, 2009 at 1:07 PM, Sam Vilain <sam@vilain.net> wrote:
Show 25 quoted lines
> 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