On Feb 10, 2009 2:42pm, Thomas Rast <trast@xxxxxxxxxxxxxxx> wrote: > Some ideas: > > First you can try to reset the git-svn head to the SHA of the commit > before (in case the one it stopped at ended up being corrupted). For > example, if $stopped is the commit you interrupted it at, > > git update-ref refs/remotes/git-svn $stopped^ > > Adjust the ref name if you used a trunk/branches layout. Then remove > the .git/svn/ cache and try again. Thanks for the suggestion. I'm not entirely sure what you mean by "Adjust the ref name if you used a trunk/branches layout." - in what way do I need to adjust it? Would something like "refs/remotes/trunk/git-svn" be right? At least that ref corresponds with a file relative to the .git-folder. Yes, I use a trunk/branches-layout... but I'm fetching a branch that has been moved (multiple times), so git-svn seems to try to fetch something called "trunk@54516"... perhaps the "@ 54516" Anyway, I tried doing the following: git update-ref refs/remotes/trunk/git-svn <SHA1 of old revision> rm .git/svn git svn fetch git then outputs something like this: r<some rev> = <some SHA1> r<some rev> = <some SHA1> ...lots and lots of these... r<some rev> = <some SHA1> r<old revision> = <SHA1 of old revision> r<some rev> = <some SHA1> r<some rev> = <some SHA1> ...some more lines... r<some rev> = <some SHA1> Done rebuilding .git/svn/trunk@<some revision>/.rev_map.<some SHA1> Incomplete data: Delta source ended unexpectedly at /home/erifay01/ libexec/git-core/git-svn line 4249 This is basically the same thing I'm getting if I just delete the .git/ svn-folder and re-fetch. For the record, I decided to roll-back about 10 more revisions than where I terminated, just to be sure. > Failing that, you could test if this also happens when only looking at > a few surrounding revisions, for example if the failure was around > revision 100: > > mkdir ../new-test > cd ../new-test > git svn init <args you gave to the other git svn init/clone> > git svn fetch -r 95:105 This turns out to be a bit more tricky than I expected. You see, the project has moved inside the repo multiple times during it's life- time, and the revision where I broke the fetching is at an old location. So I tried fetching if from old location: git svn init <old path> -s . git svn fetch -r <old revision - 100>:<old revision + 100> Doing the fetch outputs nothing (git svn init outputs "the usual stuff", though). Trying to do the same thing with the new path (same as above, but with <old path> set to the path of the new location) gives the following output: Path '<old path>' was probably deleted: Filesystem has no item: REPORT request failed on '<new path>/!svn/bc/ <last rev>': File not found: revision <last rev>, path '<old path>' Will attempt to follow revisions r<old revision - 100> .. r<old revision + 100> committed before the deletion ... And then nothing. So, I'm still quite lost here. It might be that a full re-clone is what is needed. -- 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
