Hi San,
On Fri, Nov 12, 2010 at 3:20 PM, San Martino <sanmrtn96_at_gmail.com> wrote:
> 2010/11/12 Erik Huelsmann <ehuels_at_gmail.com>:
>>> Do you think Subversion scales well for the following case, where
>>> /trunk contains about 5000 files and its size is 500Mb
>>> development requires 10 commits per day, 2-3 files changed per commit
>>> on average.
>>> Each commit is tagged (yes) from /trunk on the repository. How we will
>>> test the tag is a separate issue.
>>
>> Why would you want to tag each commit? A commit is a tag in itself:
>> there's a unique identifier to refer to the entire commit. This wasn't
>> the case in PVCS, RCS and CVS, but there's really no reason to tag
>> each and every commit; if you want to check out what got committed,
>> just use the revision number!
>
> Basically we need to test each commit from /tag while others proceed
> on /trunk. Before we used to lock - modify - TEST [- correct bugs]
> unlock. This really slows down the development because TEST is a long
> period while development needs to be very frequent. Now with
> Subversion we want to profit by concurrent progrommaing and testing.
You can continue on trunk/ even if you're testing an older revision of
it. Why do you need it to be in /tags before you can test it? What/why
would testing on trunk/ block your coding work on trunk?
My point is: in subversion trunk/ is an endless string of tags,
identified by their (global!) revision number. There's no need to stop
working on trunk while you test older versions. If you look at this
page: http://ci.apache.org/waterfall?show=svn-x86-macosx-gnu%20shared&show=svn-x86-macosx-gnu%20shared%20daily%20ra_serf&show=svn-slik-w2k3-x64-local&show=svn-slik-w2k3-x64-ra&show=svn-x64-centos%20gcc&show=svn-x64-ubuntu%20gcc&show=svn-debian-x86_64-32%20shared%20gcc&show=svn-trunk-rat-report
that's what the Subversion team itself is doing: commits keep coming
in; the builders lag, but catch up eventually (mostly at night :-)
We're 100% sure the builders get coherent snapshots, because that's
what the global revision number gives us.
Bye,
Erik.
Received on 2010-11-12 15:34:19 CET