Greg Stein wrote:
> On Mon, Apr 15, 2002 at 11:01:43AM -0500, cmpilato@collab.net wrote:
>
>>...
>>So, while your commit succeeded in the repository, your client was
>>Killed before the working copy was fully modified to reflect that it
>>*knew* your commit had succeeded (thus the reason why some of your
>>files were still marked for addition, and some weren't). Well, that's
>>just a bogus place to be from a working copy standpoint, as you can
>>imagine.
>>
>
> But even if it crashed, it *should* be okay, right? The WC would still show
> items to commit, the user would try it, and then get a conflict. An 'update'
> would then merge in the changes (already there!) and all would be happy.
>
> The thing is, the client should be able to die (kill -9) at any point, and
> thing should work except for a possible need to use 'svn cleanup'.
>
> Maybe we can think of some way to test for killability in the client?
>
> Cheers,
> -g
>
>
Last time I saw anybody do anything of that nature, there was a special
compile flag that caused a raise( 9 ); (pick your signal, 15,9, 11 etc) a
certain percentage of the time (fairly low). The random seed was the time
it was compiled, so any single compile was repeatable.
Essentially foo -V, or strings foo would give you the random seed for
any given binary. So the tests can be made repeatable if you want them
to be (assuming you have the same random number generator as the bug
reporter). Put the randomFailure() around the code you want to test for
failure modes.
Then make the client do stuff until it fails, and then sure the
resulting mess was recoverable. If you want extra bonus points, it
should print out the function that is calling it, possibly a backtrace.
It would probably be easiest to call signal 11 so it would dump core
and you could get a backtrace of the failure condition out of that, now
that I think about it.
No that isn't exactly a portable solution (won't work on Windows). I
don't know of anything else that gives you "killable" tests that are
repeatable. Just an idea if you really want to try that. The worst
thing about it is the warts in the code with randomFailure. We ended up
moving it to an extremely low level library that everybody referenced
and left it there. Then commented the heck out of it. I would guess
that pool creation would be my chosen place in the SVN code.
This requires hand testing to really be useful, but I don't see many
ways around that.
Kirby
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 15 20:20:51 2002