"David E. Wheeler" <david@xxxxxxxxxxxxxx> wrote: > On Apr 21, 2009, at 11:02 AM, Eric Wong wrote: > >>> bricolage/branches/rev_1_8/lib/Bric/App/ApacheConfig.pm was not >>> found in commit >>> e5145931069a511e98a087d4cb1a8bb75f43f899 (r5256) >>> >>> This seemed strange to me, so I had a look at SVN: >>> >>> svn list -r5256 http://svn.bricolage.cc/bricolage/branches/rev_1_8/lib/Bric/App/ApacheConfig.pm >>> ApacheConfig.pm >>> >>> So the file *is* there in that revision. I had been running 1.6.1.2, >>> so I >>> upgraded to 1.6.2.2 and ran `git svn fetch` again to see if it would >>> pick >>> up where it left off, but it returned the same error (please don't >>> tell >>> me I have to start over!). >> >> Interesting. I finally managed to reproduce it over the weekend. >> I'll >> try to look into it later tonight. > > Thanks, appreciate it. I've gotten around it by going back to the old > CVS repository on SourceForge and migrating that, and then migrating the > SVN repo only from after we moved to SVN. Then I'll just have to stitch > the CVS and SVN migrations together and I'll be done. Hopefully the workaround is working out for you. 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 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 :< 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. -- 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