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
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.
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
--
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