git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Sam Vilain <sam@vilain.net>
Date
Dec 20, 2009, 21:07 UTC
Message-ID
<1261343240.20752.20.camel@denix>
In-Reply-To
<6b2f9b1d0912191415n560a5a58xbe6390b1fcade854@mail.gmail.com>
On Sat, 2009-12-19 at 14:15 -0800, Andrew Myrick wrote:
Show 13 quoted lines
> 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.

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.

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.

Sam
Previous: Andrew MyrickNext: Andrew Myrick
Message 12 of 13 in “Efficiency and correctness patches for git-svn mergeinfo support”
  1. Sam VilainDec 19, 2009
  2. 1/5 git-svn: expand the svn mergeinfo test suite, highlighting some failuresSam Vilain, Dec 19, 2009
  3. 2/5 git-svn: memoize conversion of SVN merge ticket info to git commit rangesSam Vilain, Dec 19, 2009
  4. 3/5 git-svn: fix some mistakes with interpreting SVN mergeinfo commit rangesSam Vilain, Dec 19, 2009
  5. 4/5 git-svn: exclude already merged tips using one rev-list callSam Vilain, Dec 19, 2009
  6. 5/5 git-svn: detect cherry-picks correctly.Sam Vilain, Dec 19, 2009
  7. Sam VilainDec 19, 2009
  8. Sam VilainDec 20, 2009
  9. Eric WongDec 21, 2009
  10. Sam VilainDec 19, 2009
  11. Andrew MyrickDec 19, 2009
  12. Sam VilainDec 20, 2009
  13. Andrew MyrickDec 20, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.