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

Re: Brain dump: possible 1.7 work packages

From: Hans-Emil Skogh <Hans-Emil.Skogh_at_tritech.se>
Date: Thu, 11 Feb 2010 09:20:55 +0100

>>> - bisect /
>>> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/Feature /
>>> Proposals/Bisect.txt /
>> Even with your detailed description, I simply can't see any benefit of
>> implementing this in TSVN at all.
> I need to do the bisection thing every couple of weeks:
> As soon as the contributions to a project or module don't
> come from yourself, it can be hard to "guess" what change
> causes a certain change in behavior (e.g. unexpected side-
> effects).

I like the idea of a bisect feature, but isn't this something that should go in the core SVN implementation as well? Are there any direct benefits of doing this in TSVN instead on SVN?

>> Let's face it: 90% of all users don't even have an automated build
>> script for their source. Those who have, have a script that doesn't
>> return TRUE/FALSE for another app to catch.
> Almost 100% of professional programmers do have automatic /
> scripted build. If the project is simple, no script might exist (yet)

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.
 
> 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.

>>> - experimental patch recorder /
>>> (a simple implementation for "offline / pre-recorded commits") /
>>> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/Notes/Feature /
>>> Proposals/PatchRecorder.txt /
>>> Already working on this. /
>> Wouldn't it be better to implement this in the svn library? I'm sure
>> you'll get commit access if you send your specs to the svn dev list.
> IMHO, there are some good reasons to first pilot the
> *use-case* in some client. But I will make a separate
> post on that.

I would absolutely love this feature! But I must agree that it would make much more sense for it to be implemented in SVN instead of TSVN...

Hans-Emil

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2446628

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-11 09:21:10 CET

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

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