What version control system is best designed to *prevent* concurrent editing?

Question

We've been using CVS (with TortoiseCVS interface) for years for both source control and wide-ranging document control (including binaries such as Word, Excel, Framemaker, test data, simulation results, etc.). Unlike typical version control systems, 99% of the time we want to prevent concurrent editing - when a user starts editing a file, the pre-edit version of the file becomes read only to everyone else.

Many of the people who will be using this are not programmers or even that computer savvy, so we're also looking for a system that let's people simply add documents to the repository, check out and edit a document (unless someone else is currently editing it), and check it back in with a minimum of fuss.

We've gotten this to work reasonably well with CVS + TortoiseCVS, but we're now considering Subversion and Mercurial (and open to others if they're a better fit) for their better version tracking, so I was wondering which one supported locking files most transparently. For example, we'd like exclusive locking enabled as the default, and we want to make it as difficult as possible for someone to accidentally start editing a file that someone else has checked out. For example when someone checks out a file for editing, it checks with the master database first even if they have not recently updated their sandbox. Maybe it even won't let a user check out a document if it's off the network and can't check in with the mothership.

Ecstatic

Wikipedia as an excellent article comparing products: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software – Lionel

Answer 1

Subversion offers enforced locking. When the Propoerty svn:needs-lock is set, the file is checked out read-only and the user needs to lock it to get an writable working copy. No other user can get the same file locked from there.

Embank

But you'd still have to enforce that all files have the svn:needs-lock property; not just the existing ones but newly added ones as well. svn autoprops can do that but then you have to make sure that each client has the correct autoprops configuration. tsvn:autoprops is another option if you use only tortoiseSVN, but it won't work if users check out a sub-folder of the project :-( – Malvia

This can done in the config file for every client (miscellany: enable-auto-props = yes, auto-props: *=svn:needs-lock). Check the client setting by an pre-commit hook on the server rejecting non-locked checkins – Embank

Answer 2

I know it's not on your list, but we have been happy with Perforce. You can prevent multiple checkouts with

Your Perforce administrator can use the p4 typemap command to ensure that all files of a specified type (for instance, //depot/.../*.gif for all .gif files) can only be opened by one user at a time. See the Perforce Command Reference for details.

Cattima

Compared to P4, Subversion's implementation of this feature is "greatly lacking". It's high on my list of reasons why a company would choose P4 over SVN, and low on my list of places in SVN I expect to see significant improvement in the near future. :o – Logos

When p4 does this to me, I just "chmod u+w file" and that's the end of that problem. p4 is the worst version control tool ever designed. – Corder

Can perforce block users from using "reconcile offline work"? – Disini

Answer 3

Sounds like Subversion with TortoiseSVN would fit the bill. As Arne Burmeister mentioned, you can default it to needs-lock mode, where every file checked-out will be read-only until you get a lock on it. Through the use of hooks you can have it notify other users when a file is locked or unlocked.

TortoiseSVN integrates with Windows explorer so requires little computer savvy.

Note that Subversion has a "steal lock" feature, but you can disable this if you wish through the use of the PreLock hook.

Fiddlewood

As long as the team members are sensible (can do effective communication), there's no need to disable the "steal lock" feature. – Dipterocarpaceous

The question states, "we want to make it as difficult as possible for someone to accidentally start editing a file that someone else has checked out" – Omegaomelet

Answer 4

You mention Mercurial, and despite being a Mercurial developer, I must agree with the suggestions to use Subversion. Mercurial is all about letting people develop in a distributed fashion. This includes making private commits which are only shared with others at a later time. In other words -- Mercurial makes no attempt to lock files on a central server (there is not even a concept of a central server).

Go with Subversion, it is as fine a centralized revision control system that you'll find (I have only tried the open source systems, I don't know anything of closed source systems). If you want, you can still experiment with hgsubversion "on the side".

Arieariel

Answer 5

I know IBM ClearCase prevents that. We use it for that reason in our company.

Starch

Answer 6

If it's only documents (like word, excel, etc.) you could have a look at Alfresco's Document Manager, it's pretty simple to use.

http://www.alfresco.com/products/dm/features/

Lorelle

Answer 7

The original RCS. When checking out a file, you lock it: "co -l filename". Thereafter, until you check it back in ("ci filename"), no one can alter the file.

Lohrman

Answer 8

I don't think any distributed version control, like mercury or git, is going to work for you here. SVN has only the most basic features for locking - and the file is set readonly, which in the likes of some office tools, means you can edit it, then find you can't save it until you check it out, then you check it out only to find that the server version was different, and you either loose the server version or your local version.

I can't believe I'm saying it, but if you want to work that way, then visual source safe is the only system I know of designed like that. If you want a more modern/reliable version, look at sourcegear's Vault - although they went to great efforts to make something that looked like vss but worked well in an svn like environment.

But perhaps a dedicated document management solution would be better - or perhaps even something like portal server.

Finnic