[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checksum mismatch after canceling conflict resolution

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-11-02 19:34:31 CET

On 11/2/07, David Glasser <glasser@davidglasser.net> wrote:
> On 11/2/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> > Hyrum K. Wright wrote:
> > > David Glasser wrote:
> > >> On 11/2/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
> > >>> I've been spending some time this morning playing around with
> > >>> interactive conflict resolution, and ran across this little gem:
> > >>>
> > >>> hwright@spock:~/test/greek.wc$ svn up
> > >>> Conflict discovered in 'iota'.
> > >>> Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : h
> > >>> (p)ostpone - mark the conflict to be resolved later
> > >>> (d)iff - show all changes made to merged file
> > >>> (e)dit - change merged file in an editor
> > >>> (i)nteractive - prompt for each conflicting hunk
> > >>> (r)esolved - accept merged version of file
> > >>> (m)ine - accept my version of file
> > >>> (t)heirs - accept their version of file
> > >>> (l)aunch - use third-party tool to resolve conflict
> > >>> (h)elp - show this list
> > >>>
> > >>> Select: (p)ostpone, (d)iff, (e)dit, (h)elp for more options : d
> > >>> --- .svn/text-base/iota.svn-base Fri Nov 2 09:35:14 2007
> > >>> +++ .svn/tmp/tempfile.tmp Fri Nov 2 09:35:20 2007
> > >>> @@ -1 +1,5 @@
> > >>> -This is the file 'iota'.
> > >>> +<<<<<<< .mine
> > >>> +This is the file 'iota'. asdf
> > >>> +=======
> > >>> +This is the file 'iota'. 1234
> > >>> +>>>>>>> .r2
> > >>> Select: (p)ostpone, (d)iff, (e)dit, (r)esolved, (h)elp for more options
> > >>> : subversion/svn/main.c:934: (apr_err=200015)
> > >>> svn: Caught signal
> > >
> > > This is where I hit ctrl-C.
> > >
> > >>> hwright@spock:~/test/greek.wc$ svn up
> > >>> At revision 2.
> > >>> hwright@spock:~/test/greek.wc$ svn up -r1
> > >>> subversion/libsvn_wc/update_editor.c:2032: (apr_err=155017)
> > >>> svn: Checksum mismatch for '.svn/text-base/iota.svn-base'; expected:
> > >>> '0a18339a4d1bddab170f4811a8ef6384', actual:
> > >>> '2d18c5e57e84c5b8a5e9a6e13fa394dc'
> > >>> hwright@spock:~/test/greek.wc$ ls
> > >>> A iota
> > >>> hwright@spock:~/test/greek.wc$ svn up -r0
> > >>> D A
> > >>> D iota
> > >>> Updated to revision 0.
> > >>>
> > >>> As a result of canceling the conflict resolver in operation, it appears
> > >>> that some metadata in the wc wasn't updated correctly. I couldn't
> > >>> update to r1, but I could update to r0 and then back to r1.
> > >>>
> > >>> Is this intended behavior?
> > >> Absolutely not. The wc should never be corrupted.
> > >>
> > >> Do you have an automated reproduction script (perhaps one that at one
> > >> point echoes "hit ctrl-C during the next prompt")?
> > >
> > > Sure, I can create such a script. In the mean time, I've noted above
> > > where I hit ctrl-C.
> >
> > This triggers the problem without using ctrl-C:
> > [Assumes greek.wc and greek-2.wc are checked out greek trees from the
> > same repository.]
> >
> > echo "asdf" >> greek.wc/iota
> > svn ci greek.wc/iota -m 'asdf'
> > echo "1243" >> greek-2.wc/iota
> >
> > # This causes a premature abort
> > echo "d\n" | svn up greek-2.wc
> >
> > # WC-corruption here
> > svn up greek-2.wc -r 1
>
> Want to know something hilarious?
>
> If you give an EOF or a SIGINT to the "svn up greek-2.wc" during the
> conflict prompt, you end up with a corrupted wc. (In this case, the
> entries file believes that iota is at r2 even though both its
> text-base and checksum are still for r1.)
>
> If you just kill -9, though, everything is happy; the wc is locked,
> but "svn cleanup" fixes that. And no corruption :)
>
> So somewhere in our error handling or pool cleanup chain there is a
> "helpful" function that loggily bumps the revnum on iota. Now to find
> it...

My good friend GDB tells me that, at the time that the conflict
handler is called, the following is in the parent directory's log
accumulation buffer:

<modify-entry
   name="iota"
   present-props=""
   cachable-props="svn:special svn:externals svn:needs-lock"
   has-prop-mods="false"
   has-props="false"/>
<modify-entry
   committed-rev="2"
   committed-date="2007-11-02T18:31:36.166516Z"
   name="iota"
   last-author="glasser"
   uuid="d6c9db28-8971-11dc-b25b-3577afaf3c19"/>
<modify-entry
   text-time="1970-01-01T00:00:00.000000Z"
   name="iota"
   url="file:///tmp/x/repos/trunk/iota"
   kind="file"
   deleted="false"
   working-size="-1"
   absent="false"
   revision="2"/>

So it's already committed to updating the file entry, without having
dealt with the text-base yet...

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 19:34:42 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.