git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomas Carnecky <tom@dbservice.com>
To: B Smith-Mannschott <bsmith.occs@gmail.com>
Cc: "Edward Z. Yang" <ezyang@mit.edu>, git <git@vger.kernel.org>
Subject: Re: Interest in locking mechanism?
Date: Tue, 12 Jan 2010 19:37:47 +0100	[thread overview]
Message-ID: <4B4CC17B.30303@dbservice.com> (raw)
In-Reply-To: <28c656e21001121029h42544f3er6eedf8465851fec1@mail.gmail.com>

On 01/12/2010 07:29 PM, B Smith-Mannschott wrote:
> On Tue, Jan 12, 2010 at 19:10, Edward Z. Yang<ezyang@mit.edu>  wrote:
>> 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.
>>
>> I was wondering if there would be interest in such a feature on
>> the Git developers side.
>
> How do you imagine that this would work in a distributed system such
> as git? What would it mean to have the lock for "a file", when each
> user effectively has their own branch?

He mentioned a shared working copy, in which case there can be problems 
if multiple users edit the same file.

Usually you'd work around that by cloning the repo, working in the 
clone, and push the result back. This can get a bit tricky if the main 
repository is not bare, but there is a solution even to that (either 
explicitly run git reset --hard or have a post-receive hook which 
updates the working tree).

tom

  parent reply	other threads:[~2010-01-12 18:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-12 18:10 Interest in locking mechanism? Edward Z. Yang
2010-01-12 18:29 ` B Smith-Mannschott
2010-01-12 18:33   ` Edward Z. Yang
2010-01-12 18:37   ` Tomas Carnecky [this message]
2010-01-12 19:01 ` Avery Pennarun
2010-01-12 19:11   ` Edward Z. Yang
2010-01-12 19:24     ` Avery Pennarun
2010-01-12 19:33       ` Martin Langhoff
2010-01-12 19:43         ` Edward Z. Yang
2010-01-12 20:25         ` Avery Pennarun
2010-01-12 19:26     ` Martin Langhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B4CC17B.30303@dbservice.com \
    --to=tom@dbservice.com \
    --cc=bsmith.occs@gmail.com \
    --cc=ezyang@mit.edu \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).