On 12/13/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> I fail to see how the merge tracking feature is *any* different.
> Real-world, adhoc testing should not be the first line of quality
> assurance -- it should be the *last*, after well-written, automated unit
> and functional tests. Besides, to truly test the merge tracking
> feature "in real life", you need to exercise the breadth of real-world
> branching and merging scenarios, perhaps in ways that are foreign to our
> own development processes. And there's the rub -- I don't see our
> repository as a playground.
>
> If the folks doing merge tracking think the implementation is ready to
> fly, put it into an RC and we'll upgrade svn.collab.net. Otherwise, I
> vote against burdening the whole of the development process while they
> work out the kinks, *especially* when we're talking about repository
> data storage changes.
I'm not convinced that a feature like this is going to get anywhere
near the level of real-world use case testing that it should have if
we don't actually use it. The only cases of new features that
absolutely require server side support that we've added since 1.0 that
I can think of are locking, ra_replay, and this. For locking sticking
it on svn.c.n would not have actually resulted in any real-world
testing. For replay the feature was sufficiently constrained that I
think it was simple enough to say "yep, this satisfies the use case"
without a bunch of real-world testing. With merge tracking I really
do think that the feature could seriously benefit from actual users
using it before we actually say "yep, it's done", even if just so we
can prove to ourselves that the user interface makes sense. I think
that a period where we eat our own dogfood would result in a more
useful feature in the end, and I think it's relatively low risk. Yes,
it's true that real-world tests on svn.c.n don't span the entire range
of use cases, but they do cover at least a subset of them, and I think
there's some benefit to doing it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 13 23:11:37 2006