Re: git-svn fetch failure: index.lock file exists
Thanks, Eric. I managed to get things working before your response which means that (a) I'm a bit fuzzy on what I did and (b) I didn't record all the various messages that might be useful for debugging.
I ended up having to delete the entire .git/svn/libbid-last-merge directory, as the fetch failed even with the lockfile removed. After that, git-svn fetch retrieved a lot of old changes which had already been synched before but seems to have gotten itself back into a consistent state.
As for whether or not I interrupted a previous fetch, it's possible, but I don't remember doing so. I'd been doing mostly rebases against the trunk, though, so any corruption could have occurred some time back.
If I run into any more problems, I'll let you know and provide more detailed feedback about the types of errors I'm seeing and the steps required to correct it. Otherwise, I'll chalk this up to a one-off failure due to a poorly timed interrupt.
Ollie
On Nov 17, 2007 1:15 PM, Eric Wong <normalperson@yhbt.net> wrote:
Show 33 quoted lines
>
> Ollie Wild <aaw@google.com> wrote:
> > Hi,
> >
> > I've been using git-svn for a while now to work on gcc. Last night, I did a
> >
> > git svn fetch
> >
> > and got the following failure:
> >
> > Found possible branch point: svn+ssh://aaw@gcc.gnu.org/svn/gcc/trunk =>
> > svn+ssh://aaw@gcc.gnu.org/svn/gcc/tags/libbid-last-merge, 128810
> > Found branch parent: (tags/libbid-last-merge)
> > 789aa951bbc6a49f791bf5109136335fc33222c5
> > fatal: unable to create
> > '.git/svn/tags/libbid-last-merge/index.lock': File exists
> > read-tree 789aa951bbc6a49f791bf5109136335fc33222c5:
> > command returned error: 128
> >
> > Naively, it looks to me like I've just got a stale lock file from a
> > previous run. However, I have no idea what the correct recovery
> > strategy is. Can I just delete the lock file? Do I need to do some
> > sort of data validation?
> >
> > I'm using git version 1.5.2.5 with subversion version 1.4.5 (r25188).
>
> Did you interrupt git-svn in a previous run? But you should be able to
> just remove it; git-svn should verify that the index is in a consistent
> state before it attempts to fetch again.
>
> --
> Eric Wong
>