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 [off-list ref] wrote:

Ollie Wild [off-list ref] wrote:

quoted

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