From: Lieven Govaerts [mailto:firstname.lastname@example.org]
Sent: Fri 12/15/2006 9:55 PM
To: Michael Pilato
Cc: Nik Clayton; David Glasser; Ben Collins-Sussman; Subversion Developers
Subject: Re: merge-tracking and svn 1.5
C. Michael Pilato wrote:
> I suspect that merge tracking testing is no more complex than any other
> test, but *unlike* most of our other testing, it involves arbitrarily
> large and/or deep-historied datasets. Most of our regression tests can
> do their job in under 5 revisions of change. Merge tracking tests
> almost certainly need a bigger and more branch-ful / history-interesting
> dataset to play with.
> Because of this, I unfortunately can't help but to suspect that the push
> for "real-world testing" comes partly out of a lack of willingness to
> invest the required energies into writing fully automated functional and
> regression tests for this feature. It's simply going to take a
> non-negligible amount of time to define and compose those tests, and
> that work isn't very glorious.
Next to the unit tests (both the ones in C as the python tests), the
merge-tracking feature requires data-driven tests, which test a small
number of use cases with a large number of different data sets. Our test
framework doesn't support this kind of tests very well, as setting up a
test repository even with a few revisions requires an overwhelmingly
large amount of lines of code.
I am attaching the small load test script which I use to test whether 'mergeinfo' index gets updated or not.
All it does is
a) creates number of branches as /branches/b1..../branches/bn of /trunk.
b)creates some unique change in it.
c)merge those changes back to trunk
I typically give 20 branches and expect 20 records in 'mergeinfo_changed' table and 210 records in 'mergeinfo' table.
I believe this testscript can be extended to add other test scripts.
Received on Fri Dec 15 20:30:48 2006
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org