> Now there definitely are more examples of large installations of
> Subversion, yesterday I heard of a company with 1000+ developers on
> Subversion and there definitely are more examples of that.
Unfortunately we (the Subversion community) really do need actual
case-studies explaining how they dealt with Subversion issues when
implementing on this scale.
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.
Of course that's not real-world
1. Almost certainly, most devs will commit more than once a week.
2. Commits are not likely to be evenly distributed across the working day.
3. With 1000 devs, you probably don't have them all on one project and
you can easily have one repository per project.
Add to that possibilities that
1. Not all 'devs' are committers (does 'dev' include testers in this
case-study).
2. the 'devs' may not all be in the same time-zone.
I'm sure there are more questions about the reality of a 1000 dev
scenario but my point is, this is exactly what is needed. Not
because the information makes Subversion better (that's dilbert
thinking), but because it makes Subversion less risky (PHB thinking).
It's a shame that companies aren't willing to announce managerial
success by publicising the success of saving money by avoiding
licenses and increasing productivity.
Here's hoping I can, without such material, convince my current
company to move from CVS (which they acknowledge has issues that
subversion resolves) to Subversion which they see as immature and new
due to the lack of decent publicity.
IMHO Subversion has the potential to achieve a landslide victory over
the majority of its competitors if only provided with a little
business thinking now that the important technical thinking has
yielded good results.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 20 01:48:18 2006