>> In an ideal world every project would have version control coupled with
>> continous integration and automated tests. In reality my experience says
>> this is far from the case. I don't mean that we shouldn't support a good
>> feature just because a minority of the projects would benefit of it
>> today, I think that the bisect feature is another good case WHY you
>> should have automated tests.
> Sure, but reality is different: most companies don't even use version
> control, and those who do don't have a simple build script.
This was exactly what I was trying to say. :-)
>>> Standard workflow an iteration:
>>> (1) manually track test results, pick next revision to test
>>> (2) delete old working copy (or cleanup existing one)
>>> (3) c/o new working copy (or update to revision)
>>> (4) run build
>>> (5) test
>> Hmm... I don't see how you can delete the working copy. You would need
>> to modify it (by adding the new test that tests the changed behaviour)
>> before bisecting it. Otherwise it's just a case of someone not running
>> the tests before committing, and that is (hopefully) more easily solved
>> by adding the tests to the build step, or pre-commit step.
> Wouldn't that be a new 'feature' that CVS had: 'clean copy'.
Yes, that was what Stefan^2 suggested, but I think that it is not needed. The existing TSVN update to revision is what would be needed. To completely "clean" the working copy would remove any added tests that are needed to trigger the error.
Hans-Emil
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447645
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-15 08:43:07 CET