Hello Robert, Eric, and everyone,
Here's a situation I've encountered more than once when working with (or rather "against") VSS (in its default "Lock-Modify-Unlock" locking mode):
Alex and Beth both gets the latest version. Alex starts working on File_1, and so locks it; meanwhile Beth starts working on File_2, and so locks that.
Later, Alex finds that he also needs to edit File_2, and Beth finds that she also needs to edit File_1. Thus they are deadlocked, and will have to have a fight out in the car park to decide who is going to surrender their lock.
VSS's other mode, the "multiple checkout mode" is something of hybrid. At first, it seems rather like a "Copy-Modify-Merge" model. However, you soon come to realise that it is no longer "true C-M-M" any more than it is "true L-M-U", hence my term "hybrid".
I have come across a problem even here, again more than once:
Alex and Beth both get the latest version. Alex locks File_3. A little later, Beth makes changes to many files including File_3 and another file, File_4. Now Alex finds that he needs to edit, and therefore lock, File_4. Although he can do this now (whether still locked by Beth for further development or not), his locked version of File_3 not longer compatible with her latest version of File_4. Alex needs Beth's version of File_3 now, and therefore all the other files in the set. (Like labels, locks can only be applied to the latest version of a file, and can't be applied retrospectively to an older version despite the fact that they can be held if they were applied in the past. And of course, with no atomic commits, it is relatively difficult to determine the minimum required set of files to get the latest version of.) Thus Alex will need to unlock File_3, to a (manual?) merge and then relock it.
Thus to use VSS's hybrid model, you really need to lock all the files you might conceivably need to change in advance, and together. The only way to be *sure* that you have locked enough is to lock everything, which is impractical for other reasons. (The view of locks on the database is not of no practical use any more, for example.)
When I proposed migration of my team's sources from VSS to SVN there were some reasons to resist.
With VSS, if you look at the "database", you can see who is working on which files (in whichever locking mode). This can be helpful when deciding upon a range of coding tasks, as you can estimate the complexity of any resulting merge. It's not foolproof, as it obviously doesn't let you see into the future to see which files will be locked by others over the duration of your chosen task.
(Perforce has a command to request editing a file, thus the Perforce approach is similar, but better, than that of VSS; with Perforce you can see the locks across your team, I believe.)
In practice, we have not missed this view of locks. The ability to work on a base from any revision is often useful. The update process seems to run very smoothly, considering that it is essentially a merge. SVN also has the massive advantage that it's the working copy that points to the repository, and not the other way around (setting on the server per user/machine combination as with VSS).
Merging is a pain with either VSS or SVN (or any other VCS for that matter) if branching is not managed carefully. That's another story, really. However, I have found merging much more straightforward with SVN than with VSS. I think locks really come into play when doing a merge. With SVN, a file or directory can still be locked (either with SVN advisory locks, or with a "fascist" commit hook); thus when undertaking a major merge, the target directory, say, of the merge may be locked, which makes the process a little more manageable.
Somewhat off-topic: My personal worry was that in VSS, we used labels very heavily. I was not familiar with the tags approach. SVN does need to be supplemented with scripts to be able, for example, to view a history/log of a file relative to the revisions copied to tags; so it didn't do what I wanted "out of the box". On the other hand, the ability to able to create a tag cheaply and "retrospectively" is an *enormous* benefit.
Rob.
> -----Original Message-----
> From: Robert Graf-Waczenski [mailto:rgw@lsoft.com]
> Sent: 08 November 2006 08: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
_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.
This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 17 12:07:10 2006