Just one question:
Why is the link secured by a login+password?
JensG
Von: Hans-Emil Skogh [mailto:Hans-Emil.Skogh_at_tritech.se]
Gesendet: Donnerstag, 11. Februar 2010 09:21
An: dev_at_tortoisesvn.tigris.org
Betreff: Re: Brain dump: possible 1.7 work packages
>>> - 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=2446771
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-11 19:19:44 CET