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

Re: Testimonials++

From: Talden <talden_at_gmail.com>
Date: 2006-10-20 03:01:26 CEST

> On Oct 19, 2006, at 18:47, Talden wrote:
> > Consider that with 1000 devs, committing once a week each you've got
> > something like one commit every 3 minutes in an 8-hour day. You can't
> > commit without updating so you update - an update would therefore need
> > to be guarenteed to complete inside 3 minutes.

On 10/20/06, Ryan Schmidt <subversion-2006d@ryandesign.com> wrote:
> Not true. You most certainly can commit if you are not at the HEAD
> revision. You only need to be at the HEAD revision of the files and
> directories you're currently committing. Of course, if 1000
> developers are all committing the same files all the time, then you
> might run into more conflicts than you would like, but I'm not sure
> that's a realistic scenario.

Being at the head revision requires updating right. Sure you're not
updating the entire working copy (just the subtree that encompasses
the full scope of the commit).

So you finish your task, you update, you test, you go to commit.
Whoops gotta update. Since you only have 3 minutes on average before
the HEAD advances again, there's no way you can update and do any
reasonable checking, you just hope there are no adverse interactions
and commit.

I'm not suggesting it's a realistic scenario - surely people aren't
working this way...

1000 devs on the one project (not product) would be a nightmare to get
any reasonable release time-frame from. Any product requiring 1000
devs surely should be partitioned into multiple projects for better
management and I expect that a real-world example would show this
quite well.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 20 03:02:02 2006

This is an archived mail posted to the Subversion Users mailing list.

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