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

From: Eric Wong <normalperson@yhbt.net>
Date: Apr 26, 2009, 01:53 UTC
Message-ID: <20090426015300.GA17212@dcvr.yhbt.net>
In-Reply-To: <8EDD65AC-9C25-4281-86F6-E52A41331B00@kineticode.com>

"David E. Wheeler" <david@kineticode.com> wrote:

Show 27 quoted lines

> 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