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

"David E. Wheeler" [off-list ref] wrote:

On Apr 21, 2009, at 11:02 AM, Eric Wong wrote:

quoted

quoted

   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