These points are exactly what I'm selling to, except that also the
committers are geographically dispersed across several continents,
meaning that races between clients are a real consideration.
In the enterprise scenario it's important to be able to bound the
worst-case scenario. The emphasis isn't on guaranteeing that Bad Things
never happen but rather on guaranteeing that no matter how bad things
get there is a recovery plan of known cost in time & effort.
For example I plan to look into having a server-side hook save a full
plain-text copy of every file that is changed. The point is not that
anyone thinks this is needed but rather that by doing this I need not
worry about a number of unlikely scenarios.
PS. The other big difference between open-source and enterprise
environments is the need to support lame users. The larger an
enterprise gets the more people you have inhabiting the wrong side
of the Bell Curve. Such people aren't attracted to open-source in
the first place or quickly go away, but in the enterprise they
form a sizeable population and may be impossible to get rid of.
> Date: Mon, 18 Aug 2003 10:00:03 -0700
> From: Jack Repenning <jrepenning@collab.net>
>
> Oh, yes, this is a real use case. It's more an enterprise thing than
> an open-source one, I suppose, so perhaps it's outside the "better
> CVS" touch-stone for SVN 1.0. The combination of things that drive
> some enterprise communities into this level of care are:
>
> * many many committers (hundreds, occasionally thousands) all with
> commit rights to the same files (or to all files)
>
> * diverse change mix (patches, maintenance, new development)
>
> * pervasive changes (like ports to new platforms, changes in core
> data structures)
>
> * paying customers who won't stand for disruption
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 19 07:01:55 2003