> > Granted, SCM models aren't my area of expertise. But I'd
> love to hear
> > someone argue a strong case for lock-modify-unlock. I'd love
> > to hear a
> > one-sided argument for the other side. :-)
I don't think I have the time go over all the pros and cons of both
models. However, I can say that the one area in which the
copy-modify-merge model totally fails is when dealing with files that
you can't merge. (Not too surprising when looking at the title of the
model.) This includes many popular binary file formats: images (imagine
working in a graphics house using a merging model), spread sheets,
presentations, etc.
It also isn't recommended for files that, while are textual, you
_shouldn't_ merge. I would not want to have to deal with the conflicts
in a PostScript file.
This is why many source control management systems allow you to use a
combination of both lock-modify-unlock and copy-modify-merge. For
example, Perforce, StarTeam and ClearCase are three SCMs that I can
think of off the top of my head that allow you to exclusively lock a
file, but do not require you to do so. If I remember correctly (in
other words, I can't remember), CVS's locking abilities was severely
limited. Subversion's locking mechanism ... Well ... Let's just say
that it's a gating issue preventing us from adopting it into our
environment. Until SVN has locking fully implemented, we can't consider
SVN as a viable replacement for our current SCM system (just thinking
about having to explain to a manager or a document writer how to merge
two binary documents together gives me the shudders).
So, just my $0.02CAD, which in USD is$0.014USD, and thus not very much.
Basically, both models are needed. You will not find a good
lock-modify-unlock system that doesn't support dirty files, or a good
copy-modify-merge system that doesn't support locking. In fact, the
best systems out there support both models.
--
Jay Glanville
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 3 20:15:09 2004