Re: git-svn segmetation fault

[Eric Wong <normalperson@yhbt.net>]

Wink Saville <wink@saville.com> wrote:
> Wink Saville wrote:
> >I was doing an git-svn dcommit and got a seg fault. The first
> >phase of updating svn completed and then it seg faulted on the
> >second. So I suspect I'm out of sync and need to recover,
> >any guidance appreciated.
> >
> >If it's any help the svn repo is at 
> >http://async-msgcomp.googlecode.com/svn.
> >If someone needs it I happen to have a backup of the git repo before
> >doing the commit and then after the seg fault.
> >
> >If there is any other information that someone needs I can try
> >to supply it.

Which version of the SVN bindings do you have installed?

> >Cheers,
> >
> >Wink Saville
> <snip/>
> 
> 
> <As an update, I first tried to re-execute the dcommit, but that didn't 
> work: />
> 
> wink@ic2d1:$ git-svn dcommit
> Committing to https://async-msgcomp.googlecode.com/svn/trunk ...
> Merge conflict during commit: Your file or directory 
> 'android/hmc/src/com/saville' is probably out-of-date: The version 
> resource does not correspond to the resource within the transaction.  
> Either the requested version resource is out of date (needs to be 
> updated), or the requested version resource is newer than the 
> transaction root (restart the commit). at /usr/bin/git-svn line 420
> 
> <I than did a rebase that got me back in sync: />
> 
> wink@ic2d1:$ git-svn rebase
> Index mismatch: 94bbfa6d433192de71060d1274f0b0eab8f49a30 != 
> 2fcd3a5cc5a9ca062a41d0ff5ac30073f4fa23b0
> rereading 8ce31b64294bdb063c64c50b9358533ac8746af4

<snip long list of files>

>        A       COPYING.LESSER
>        A       COPYING
>        A       AGPLv3.LICENSE
> r52 = 2336c1c70e92d572f5a1b248249b4f857142bc51 (git-svn)
> First, rewinding head to replay your work on top of it...
> HEAD is now at 2336c1c... Refactor to reduce duplicated code and have 
> pure Java Hmc/ActiveHmc.
> Nothing to do.

So it appears the dcommit succeeded in making the change to the
repository, but segfaulted afterwards (when attempting to retreive
the version number of the commit.   Is that assessment correct?

-- 
Eric Wong