You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2007/11/02 14:39:57 UTC
Checksum mismatch after canceling conflict resolution
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
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?
-Hyrum
Re: Checksum mismatch after canceling conflict resolution
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
David Glasser wrote:
> I took this to a new thread: Re: Flushing directory log accumulator
> during pool cleanup (Re: svn commit: r23342 -
> trunk/subversion/libsvn_wc)
>
> There's even a patch to review!
wOOt! Thanks for taking a look at this, Dave.
-Hyrum (who for once found a real bug, and not just operator error. :)
Re: Checksum mismatch after canceling conflict resolution
Posted by David Glasser <gl...@davidglasser.net>.
I took this to a new thread: Re: Flushing directory log accumulator
during pool cleanup (Re: svn commit: r23342 -
trunk/subversion/libsvn_wc)
There's even a patch to review!
--dave
On 11/2/07, David Glasser <gl...@davidglasser.net> wrote:
> On 11/2/07, David Glasser <gl...@davidglasser.net> wrote:
> > On 11/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> > > Hyrum K. Wright wrote:
> > > > David Glasser wrote:
> > > >> On 11/2/07, Hyrum K. Wright <hy...@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@davidglasser.net | http://www.davidglasser.net/
>
--
David Glasser | glasser@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
Re: Checksum mismatch after canceling conflict resolution
Posted by David Glasser <gl...@davidglasser.net>.
On 11/2/07, David Glasser <gl...@davidglasser.net> wrote:
> On 11/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> > Hyrum K. Wright wrote:
> > > David Glasser wrote:
> > >> On 11/2/07, Hyrum K. Wright <hy...@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@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
Re: Checksum mismatch after canceling conflict resolution
Posted by David Glasser <gl...@davidglasser.net>.
On 11/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> Hyrum K. Wright wrote:
> > David Glasser wrote:
> >> On 11/2/07, Hyrum K. Wright <hy...@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...
--dave
--
David Glasser | glasser@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
Re: Checksum mismatch after canceling conflict resolution
Posted by David Glasser <gl...@davidglasser.net>.
On 11/2/07, David Glasser <gl...@davidglasser.net> wrote:
> On 11/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> > Hyrum K. Wright wrote:
> > > David Glasser wrote:
> > >> On 11/2/07, Hyrum K. Wright <hy...@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
>
> When you say "premature abort" here, what exactly do you see? A
> crash? (I see a "can't read stdin: end of file found").
Oh, note that 'echo "d\n"' is actually printing dee-backslash-en, so
it's being regarded as an unrecognized command. Which explains why
there's no diff printed, but not why the error message on EOF on input
sucks, or why the wc gets corrupted.
--dave
--
David Glasser | glasser@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
Re: Checksum mismatch after canceling conflict resolution
Posted by David Glasser <gl...@davidglasser.net>.
On 11/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> Hyrum K. Wright wrote:
> > David Glasser wrote:
> >> On 11/2/07, Hyrum K. Wright <hy...@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
When you say "premature abort" here, what exactly do you see? A
crash? (I see a "can't read stdin: end of file found").
--dave
>
> # WC-corruption here
> svn up greek-2.wc -r 1
>
>
>
--
David Glasser | glasser@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
Re: Checksum mismatch after canceling conflict resolution
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Hyrum K. Wright wrote:
> David Glasser wrote:
>> On 11/2/07, Hyrum K. Wright <hy...@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
Re: Checksum mismatch after canceling conflict resolution
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
David Glasser wrote:
> On 11/2/07, Hyrum K. Wright <hy...@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.
-Hyrum
Re: Checksum mismatch after canceling conflict resolution
Posted by David Glasser <gl...@davidglasser.net>.
On 11/2/07, Hyrum K. Wright <hy...@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
> 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")?
--dave
--
David Glasser | glasser@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