You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2009/10/13 15:38:00 UTC

Re: svn commit: r39975 - trunk/subversion/libsvn_wc

Greg Stein <gs...@gmail.com> writes:

> Author: gstein
> Date: Mon Oct 12 22:42:24 2009
> New Revision: 39975
>
> Log:
> Get rid of the "rerun" concept. Every operation should be able to be run
> multiple times, and it shouldn't matter whether it is the FIRST or an
> additional run.

That's the theory but does it work in practice?  How would I check?
This revision and r37254 have removed the debug code that demonstrated
how badly rerunning worked--there were loads of regression test
failures last time I tried it.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407152

Re: svn commit: r39975 - trunk/subversion/libsvn_wc

Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Stein <gs...@gmail.com> writes:

> On Tue, Oct 13, 2009 at 11:38, Philip Martin <ph...@codematters.co.uk> wrote:
>> Greg Stein <gs...@gmail.com> writes:
>>
>>> Author: gstein
>>> Date: Mon Oct 12 22:42:24 2009
>>> New Revision: 39975
>>>
>>> Log:
>>> Get rid of the "rerun" concept. Every operation should be able to be run
>>> multiple times, and it shouldn't matter whether it is the FIRST or an
>>> additional run.
>>
>> That's the theory but does it work in practice?  How would I check?
>> This revision and r37254 have removed the debug code that demonstrated
>> how badly rerunning worked--there were loads of regression test
>> failures last time I tried it.
>
> It could very well fail in practice, but all these loggy operations
> are going to disappear in favor of wc_db functions and/or workqueue
> operations. As they get shifted, then we'll ensure they can be re-run
> (which I did with the killme op).

Without regression tests there is no guarantee that rerunning won't
get broken in future.

Also testing the individual operations isn't really enough--we need to
test the sequences of operations. Take issue 2424: the individual
moves are repeatable but the sequence is not (this particular
issue might get fixed in the new code).

> [...]
> Though it is a fair question to ask how we *ensure* and debug/test that.
>
> We can "easily" test running a given workqueue operation multiple
> times. It won't really be easy/possible to test a given operation
> failing partway through, however.

The log file mechanism was supposed to be interruptable and rerunnable
but running things twice was enough to show that it didn't work like
that in practice.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407251

Re: svn commit: r39975 - trunk/subversion/libsvn_wc

Posted by Greg Stein <gs...@gmail.com>.
On Tue, Oct 13, 2009 at 11:38, Philip Martin <ph...@codematters.co.uk> wrote:
> Greg Stein <gs...@gmail.com> writes:
>
>> Author: gstein
>> Date: Mon Oct 12 22:42:24 2009
>> New Revision: 39975
>>
>> Log:
>> Get rid of the "rerun" concept. Every operation should be able to be run
>> multiple times, and it shouldn't matter whether it is the FIRST or an
>> additional run.
>
> That's the theory but does it work in practice?  How would I check?
> This revision and r37254 have removed the debug code that demonstrated
> how badly rerunning worked--there were loads of regression test
> failures last time I tried it.

It could very well fail in practice, but all these loggy operations
are going to disappear in favor of wc_db functions and/or workqueue
operations. As they get shifted, then we'll ensure they can be re-run
(which I did with the killme op).

The log_do_modify_entry code was a perfect example of this brokenness.
If I removed the test for ->rerun, then a lot of stuff broke because
the loggy function was used to create an entry, so yah: it was missing
and the function would exit. But if the intent was to create an entry,
then it should still do that on a rerun. The Proper solution would be
a create operation, and a modify operation. But I'm not going there,
in favor of just fixing it as part of the workqueue migration, and as
part of the migration away from entry_t and the "modify/create entry"
concepts.

Though it is a fair question to ask how we *ensure* and debug/test that.

We can "easily" test running a given workqueue operation multiple
times. It won't really be easy/possible to test a given operation
failing partway through, however.

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407195