Re: Again with git-svn: File was not found in commit

From: David E. Wheeler <david@kineticode.com>
Date: Apr 26, 2009, 02:40 UTC
Message-ID: <81EFD289-5E46-4B27-8DA4-C2039915CE2D@kineticode.com>
In-Reply-To: <20090426015300.GA17212@dcvr.yhbt.net>

On Apr 25, 2009, at 6:53 PM, Eric Wong wrote:

> Hopefully the workaround is working out for you.

[Finally], yes.

[Finally]: http://justatheory.com/computers/vcs/git/bricolage-to-git.html

Show 18 quoted lines

> The problem with r5256 is quite nasty and I can't think of a good
> automated solution right now involving --stdlayout/branches/tags
>
> ------------------------------------------------------------------------
> r5256 | theory | 2004-05-09 19:17:49 -0700 (Sun, 09 May 2004) | 2  
> lines
> Changed paths:
>   A /bricolage/branches/rev_1_8 (from /bricolage/branches/ 
> rev_1_8_temp/bricolage:5255)
>   D /bricolage/branches/rev_1_8_temp/bricolage
>
> Permanent home.
>
> ------------------------------------------------------------------------
>
> The problem is that the "bricolage" subdirectory became the top-level
> tree and git-svn doesn't have a way of detecting that.  This is
> occasionally a problem with other repos, too

We moved shit around a *lot*. There were two times we moved things around: First, when Bricolage was first imported from CVS, it assumed that the root directory was the project directory, even though we had several projects. So we had

/trunk/ /branches/ /tags/

We spent several hundred commits moving things around so that we would have the more standard:

/bricolage/trunk/ /bricolage/branches/ /bricolage/tags/

Fortunately, we did all of this moving before we committed anything useful to Subversion. So for this project, I first converted the old SourceForge CVS repository to Git, then converted the Subversion repository starting from after all this moving around (r5517, well after the problematic commit), and then I joined them together, as detailed in my blog post.

Show 8 quoted lines

> Overall, this repo is very nasty given the amount of times follow- 
> parent
> needs to be used (refs with a "@<revno>" suffix).  The --stdlayout
> switch is really for the common repositories with a consistent depth  
> for
> branches/tags.  Unfortunately, SVN is way too freeform in this regard
> and mixed-depth branches/tags hierarchies have always been a  
> problem :<

Tell me about it. This is why it took 30 hours before `git-svn` failed.

The other time we moved stuff around was to reorganize tags into subdirectories. This was because we had so many tags that they were unwieldy as a directory listing in SVN. This turned out to be a PITA when migrating, but I was able to [work around it] using GitX and some pretty hacky code to generate grafts. It'd be nice if there was a way to tell git-svn how deep a hierarchy to look for for tags (and perhaps branches), although it wouldn't have helped us, because we *changed* that hierarchy.

[work around it]: http://justatheory.com/computers/vcs/git/bricolage-svn-to-git.html

I'm so glad to have it all in Git now where things are far more rationally organized.

> It might be a bit easier to write (or script) the "fetch" lines
> (like the one --stdlayout generates for trunk) for each tag/branch
> and maybe use --no-follow-parent.

--no-follow-parent was indeed key for me being able to get this done. Thanks for writing such a capable client that, although it couldn't reconstruct what we were thinking when we moved things around, it let me tell it where to stop and what stuff to ignore (ultimately, I had it ignore all tag directories) so that I could get the job done.

The new Git repository is now on [GitHub], if you're curious.

[GitHub]: http://github.com/bricoleurs/bricolage/

Thanks,

David