Duh. I'm frequently using the privately-coined abbreviation "LMM"
in my text below. Instead i meant to write "LMU", which is supposed
to stand for "Lock-Modify-Unlock", so please do so here on the text:
s/LMM/LMU/g
And, of course, neither "LMU" or "CMM" are in any way official acronyms.
Robert
> -----Original Message-----
> From: Robert Graf-Waczenski [mailto:rgw@lsoft.com]
> Sent: Mittwoch, 8. November 2006 09:58
> To: users@subversion.tigris.org
> Subject: RE: Concurrent versioning = spawn of the devil?
>
>
> I can't point you to resources on the net, but I also had a discussion
> with a co-worker about this issue yesterday, so I took the time to
> summarize some parts of our discussion:
>
> To repeat other resources, here's the issue that is under discussion:
>
> VSS uses two different patterns, one is what the Subversion documentation
> calls "Lock-Modify-Unlock", i.e. before a user can edit a given file
> in his local working copy, he must acquire an exclusive lock to the file
> from the VSS server (or manually change the file to be no longer
> read-only anymore, but let's ignore this option). If someone else has
> a lock already (i.e. has VSS-checked-out the file), then the lock will
> be denied. The second pattern is a slight variation of the first, and
> is achieved by configuring VSS to support multiple checkouts, which
> means that the user still has to acquire a lock but several users
> can have a lock on the same file, meaning that several users have
> checked out the file, hence the term "multiple checkout". Normally
> you choose the first approach for binary files and the second approach
> for non-binary files because the latter can not be merged.
>
> Subversion, OTOH, by default uses the "Copy-Modify-Merge" pattern, which
> has some downsides on first glance if you are used to the VSS patterns.
> With the Subversion pattern, the user is not notified about changes by
> others until the user *commits* his own changes. In VSS, you are
> warned that
> you have not yet checked out the file and are asked to perform a checkout.
> And when you do checkout the file, you get its current version from the
> repsitory and in this way you get to see the other user's changes *before*
> you even start editing.
>
> So, when trying to compare the VSS patterns with the Subversion pattern,
> you first must make clear *which* of the two VSS patterns you are
> comparing
> against, because the good news is: Subversion also supports one of the
> two VSS patterns, namely the strict variant! What you have to do is
> set the "svn:needs-lock" property on all files that you want to be
> handled according to the stricter of the two VSS patterns. The SVN client
> then behaves much similarly to the VSS client, i.e. the read-only flag
> on the file is set etc.
> However, if your partner is in love with the multi-checkout variant of
> the VSS pattern (i think he is referring to this one since you are
> having such a hard time in your discussions with him), then you are of
> course talking about files that can be merged, i.e. non-binary files,
> right? Because otherwise, VSS would force you to use the strict pattern
> and this variant is supported in SVN, as said above.
>
> The less strict variant, however, is not supported in SVN, so we need some
> arguments why the SVN Copy-Modify-Merge does not equal "bad" and why the
> VSS "Shared Lock-Modify-Unlock" does not necessarily equal "good".
>
> Why is SVN's CMM not bad?
> -------------------------
>
> The main reason in my eyes is: If you have good merging tools, CMM is
> actually fine and there are no problems whatsoever with it. The use case
> simply is: "I want my changes to not silently overwrite changes that
> others have made to the same file". Learning that SVN waits to inform you
> about a new version in the repository as late as when you try to commit
> sounds "evil" on first glance because one is tempted to think that your
> changes are lost and you are forced to redo them. No. Wrong. Instead,
> you still have your local changes and you are asked to merge the changes
> from the repository with your own changes, yielding a merged version of
> the file. So, your changes are not lost. VSS users typically
> *hate* merging
> simply because the default merging window of the VSS explorer is such
> an awful tool to work with: No syntax coloring, no obvious pointers on
> how to apply which of the two changes and what the result will look like.
> (It *does* display all the information you need, but I frequently have
> a hard time performing a merge operation and it often leaves me unsure
> if the result is ok or not.)
>
> Why is VSS's LMM pattern not good?
> ----------------------------------
>
> In my eyes the main problem with this is that it gives you bogus
> protection. Since we are talking about a scenario where the file can be
> checked out by several peer workers (see above why), the warning that
> VSS issues to you is nothing that protects you from someone else also
> checking out the file and then checks it back in before you have time
> to checkin. So you are under the false assumption that your changes
> can be applied without conflicts and are then presented with a merge
> conflict when you check in. Note that i'm not saying that the LMM pattern
> is "bad", i'm only saying that the pattern by itself is no improvement
> versus the CMM pattern. Both patterns rely on the worker itself to make
> sure that his local changes are correctly merged with the changes that
> have occurred since the local version was retrieved from the repo.
>
> Who is the winner then?
> -----------------------
>
> This is a SVN list. So guess who wins?
>
> My personal opinion is that the LMM model is more honest to you. It does
> not attempt to give you protection that is not possible. *Any* revision
> control system must face the problem that your working copy is outdated
> vs. the current repository. Think of it as a time window issue: VSS gives
> you a short heads-up that there *might* be a new version of the file and
> gives you that new verison immediately before you begin with your changes.
> This approach sound appealing on first glance. The fact that the repo
> version of the file can be newer *again* when you try to check in is
> easily overlooked and leads to the false observation that VSS is better
> in this regard. SVN instead doesn't even try to tell you that there might
> be other changes to the file in the repository. You simply learn to
> assume that there can be changes, so you learn to update your working copy
> before you start making changes and expect naturally that you may
> encounter
> an even more recent repository when you commit your changes.
>
> I'd suggest two things:
>
> 1) If your discussion evolves around the multi-checkout variant, then
> educate him about the equation "shared file locking" = "bogus protection"
>
> 2) If you are talking about the single-checkout variant, then learn about
> SVN's support for exclusive locks with "svn:needs-lock", with this, you
> get a behavior that is as strict as VSS's and also marks your local copy
> as "read only".
>
> Robert
>
> > -----Original Message-----
> > From: Eric [mailto:spamsink@scoot.netis.com]
> > Sent: Mittwoch, 8. November 2006 07:10
> > To: users@subversion.tigris.org
> > Subject: Concurrent versioning = spawn of the devil?
> >
> >
> >
> > Can someone point me to some information on the web that I can use to
> > convince my co-developer that concurrent versioning, with
> unlocked files,
> > isn't the absolute evil that he claims it is?
> >
> > I've been arguing with him about it for half the evening and I'm
> > just about
> > out of ideas...
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 8 10:27:59 2006