At 10:08 AM -0700 8/30/03, Kumaran Santhanam wrote:
>I'm not entirely clear on why someone would share a working copy.
>Many SCM systems don't even allow this. Maybe you can provide an
>example where sharing a working copy is the only recourse?
I doubt I can convince you it's a good idea; I think it's a stupid
idea. But I also have seen it enough, and have failed often enough
to talk the people out of it, that I think I can describe what makes
people insist upon it. I'm going to tell you what they say to me;
the point here is not whether you or I think the reasons are
sufficient, only that these people feel so.
The main scenario is a team where most people don't understand
version control. One team member gets tasked to do the set-up--stuff
like picking the right branch, checking out the right set of files,
any other steps required by the local process (maybe running
autogen.sh to set up the build for the local platform). Then
individual workers can go into the wc, make localized changes, and
use the absolute minimum set of VC commands in the absolute most
tightly controlled ways--"svn ci filename". Often that's "too
complicated," even, and there's some shell wrapper that makes it
"easier," like "publish filename", or a custom-built applet they can
d&d the changed file into through the GUI. The essential motivation
for the sharing, in this case, is to minimize the labor of that one
team member: every step that needs to be done to each individual wc
is that much more work for this poor sod.
Another scenario involves a team of more general developers, maybe
quite competent in version control, doing some major rework in a
"skunk works" kind of environment. They need to see each others'
work in a timely fashion, and yet avoid exposing it to everyone else
until it's ready. You're thinking "make a branch," I hear you. But
branches are always a bit scary in any VC system (they're notorious
in CVS), and SVN 1.0 is going to be no better than average about
that, either. These people insist that the delay, confusion, and
risk of a branch are too much to impose on their fast-track,
high-visibility effort. Here, the motivation for sharing is so
everyone can build with everyone else's changes.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 31 01:22:46 2003