Robert Schiele <rschiele@xxxxxxxxx> wrote: > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html