Re: Interest in locking mechanism?

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jan 12, 2010, 19:01 UTC
Message-ID: <32541b131001121101i76ad8062p3a7f3571ad86b0ce@mail.gmail.com>
In-Reply-To: <1263319565-sup-1767@ezyang>

On Tue, Jan 12, 2010 at 1:10 PM, Edward Z. Yang <ezyang@mit.edu> wrote:

Show 8 quoted lines

> I have a few friends that still use RCS for their version control
> needs.  We have argued over various points between RCS and Git, and
> as far as I can tell the one thing RCS has that Git does not is
> a locking mechanism.  That is to say, co -l checks out a file and
> also gives you a lock on it, preventing others from futzing with it,
> and ci -u checks in the file and releases your lock.  This is
> useful if you have a shared working copy on a multiuser system or
> on a network file system, and you don't want conflicts.

If what you want is just one shared working copy with locking, then what you want is RCS. Why change what's not broken? You're not doing anything distributed or even any branching, and you don't need to atomically commit multiple files at once (which would be very confusing if more than one person is changing stuff in the current tree), so git doesn't seem buy you anything.

There are lots of arguments that the central-shared-copy-with-locking is obsolete. It's been obsolete since at least CVS (the "concurrent versions system", named after the fact that you didn't have to have one central working copy). But if you don't agree that this model is obsolete, you might as well use a tool that treats your use case as a first class citizen.

Have fun,

Avery