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

Re: following untracked parents in git-svn

From
EWEric Wong <normalperson@yhbt.net>
Date
Dec 22, 2009, 18:38 UTC
Message-ID
<20091222183829.GA7412@dcvr.yhbt.net>
In-Reply-To
<20091222102815.GA12259@sigfpe.ibm.com>
Robert Schiele <rschiele@gmail.com> wrote:
Show 22 quoted lines
> Hi Eric et al.,
> 
> While using git-svn to work with a repository with a very complex history I
> discovered a very unfortunate behavior:
> 
> In general when a branch was derived (copied) from somewhere else git-svn
> follows this parent branch and imports it.  If multiple branches do that
> git-svn detects that the corresponding parrent branch already had been
> imported and reuses the imported data.  Unfortunately when the parent
> directory in the svn repository is not tracked as a branch in the svn-remote
> section of the config file (for instance when it is just a subdirectory of a
> tracked branch) this situation is no longer detected and this parent branch is
> imported multiple times with the same result.  In a large repository this can
> increase importing time drastically.
> 
> My analysis (as far as I understand the code) is that this is because the map
> files in .git/svn are indexed by their ref name in the git repository.
> Untracked branches are indexed by the name of their following branch ref name
> followed by @XX where XX is the revision number of the branch point.
> Obviously with that scheme the index name for two branches following a common
> parent tree is different and thus an already imported tree is not correctly
> detected.

Hi Robert, I'm aware of this problem. It's not hit too often, but occassional repositories I follow tend to hit this.

Show 7 quoted lines
> My thoughts where now that this could potentially be fixed by not indexing
> those map files by their ref name in the git repository but by their location
> in the original svn repository.  Given that my understanding of the git-svn
> code is not good enough to decide about all the consequences of such a design
> change I'd like to ask you whether you think this change would be a good idea
> or whether I might have overlooked a fundamental problem that makes it
> impossible (or at least hard) to implement this idea.

Your idea sounds like it should work. Unfortunately the code is a mess and I've been lazy and lacking time/sufficient motivation to clean it up, but I'd be glad to accept patches since the test coverage is pretty good.

-- 
Eric Wong
Previous: Robert Schiele
Message 2 of 2 in “following untracked parents in git-svn”
  1. Robert SchieleDec 22, 2009
  2. Eric WongDec 22, 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.