Ben Collins-Sussman <sussman@collab.net> wrote on 05/29/2004 09:30:12 AM:
> Gary Feldman wrote:
>
> > But there's no reason for you to even get into this discussion. This
is a
> > book about subversion, not about version control systems in general.
The
> > fact that the copy-modify-merge model is popular is all the
justification
> > you need here. Just don't raise the issue at all.
>
> I respectfully disagree. A vast number of readers have experience with
> version control, specifically with systems like Visual Source Safe. For
> this audience, copy-modify-merge is a new idea, and it's deliberately
> compared to lock-modify-lock because readers *are* familiar with the
> latter model already. I can't tell you how many times that section of
> the book has been shown to pointy-haired-bosses who freak at the concept
> of copy-modify-merge. It's been exceedingly useful. A boss doesn't
> want to hear that "copy-modify-merge is popular", they need to be told
> why universal lock-modify-lock policies are harmful too.
>
> When the book is updated for 1.1, we can tone it down a bit. Locking
> *is* useful for certain situations (such as preventing wasted time
> editing unmergeable files), but it should never be the default mode of
> behavior.
>
I agree. Having that chapter in there is very useful in the corporate
world. A lot of people have the idea that you are not doing "real"
version control if you do not have locks, so it is nice to have a well
written explanation of the philosophies and why copy-modify-merge works
better. I think the chapter will only get better when it acknowledges
that there are situations where locks are needed.
I had always worked in the "locks" world and thought it was better than
the CVS model. I have been doing a lot of J2EE development lately and it
would be virtually impossible to do in a locking version control system as
there are so many XML files that EVERYONE has to be able to edit and
modify to do any work. If the file was always locked no one could ever do
anything.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 29 16:24:11 2004