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
Received on Wed Nov 8 09:59:00 2006