Interest in locking mechanism?

Interest in locking mechanism?

[Edward Z. Yang]

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.

Cheers,
Edward

Re: Interest in locking mechanism?

[B Smith-Mannschott]

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?

// Ben

Re: Interest in locking mechanism?

[Edward Z. Yang]

Excerpts from B Smith-Mannschott's message of Tue Jan 12 13:29:41 -0500 2010:
> 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?

Hi Ben,

Good question.  I don't intend for the locking mechanism to leak into
the distributed model of Git. It is solely for working copies, which /are/
centralized (just there can be a lot of them), when multiple people might
be editing the same working copy.

There is a somewhat natural question of: well, you should clone, make your
changes in your own copy, and then push them back.  That is arguably the
correct mechanism.  However, for casual users batonning changes from one
repository to another is often more overhead than is really necessary, and
I think a working copy locking mechanism will help for simple cases.

Cheers,
Edward

Re: Interest in locking mechanism?

[Tomas Carnecky]

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

Re: Interest in locking mechanism?

[Avery Pennarun]

On Tue, Jan 12, 2010 at 1:10 PM, 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.

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

Re: Interest in locking mechanism?

[Edward Z. Yang]

Excerpts from Avery Pennarun's message of Tue Jan 12 14:01:42 -0500 2010:
> 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.

I would like to respectfully disagree.  I want to use git because:

    * I use Git on a regular basis, and do not use RCS.  I constantly
      have to go digging through the manpages when I occasionally do
      stumble upon an RCS system.  Interface familiarity is nice.

    * Putting it in Git means that you can easily grow; you can decide
      "Hey, maybe we want to do branchy development" and just do it,
      rather than have to drum up the activation energy to do an
      rcsimport.

    * If code is deployed in a production context as a Git checkout,
      you can definitely have both branchy development as well as
      a shared working copy (with low contention, but contention nonetheless).

Cheers,
Edward

Re: Interest in locking mechanism?

[Avery Pennarun]

On Tue, Jan 12, 2010 at 2:11 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
>    * I use Git on a regular basis, and do not use RCS.  I constantly
>      have to go digging through the manpages when I occasionally do
>      stumble upon an RCS system.  Interface familiarity is nice.

But the users who are arguing in favour RCS would say the opposite, right?

>    * Putting it in Git means that you can easily grow; you can decide
>      "Hey, maybe we want to do branchy development" and just do it,
>      rather than have to drum up the activation energy to do an
>      rcsimport.

But then you'd have to do an import now instead of later, for no
immediate gain.  The extreme programming people would say YAGNI here;
delay the work until it's actually required, because it'll be no more
work later than it is right now.

>    * If code is deployed in a production context as a Git checkout,
>      you can definitely have both branchy development as well as
>      a shared working copy (with low contention, but contention nonetheless).

I would suggest that by the time you're doing this, you're just lying
to yourself if you think you have RCS-style locking.  People will
quite easy be able to change the same files as other people, then push
into git, and sooner or later someone will have to pull from git into
the original shared repository, possibly stomping on other people's
work.  So you end up not having the advantage you were trying to
achieve.

BTW, I will try be a bit more constructive in case you *really* want
this: I've never heard of anyone doing RCS-style locking with git, so
you're probably out of luck if you're looking for a pre-made solution.
 But it's probably rather easy to construct a simple shell script
implementation that's independent of your revision control system
(since locking files has nothing to do with revision tracking,
really).  Just make a 'co' command that writes your username to
.filename.lock and chmods the file; then write a ci command that
checks the lockfile to make sure it's yours, deletes the lock file,
git commits it, and chmods the file back again.

Have fun,

Avery

Re: Interest in locking mechanism?

[Martin Langhoff]

On Tue, Jan 12, 2010 at 8:24 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> really).  Just make a 'co' command that writes your username to
> .filename.lock and chmods the file; then write a ci command that
> checks the lockfile to make sure it's yours, deletes the lock file,
> git commits it, and chmods the file back again.

Actually -- on the same track but even better: if you are using a
unixy system, you are likely to have all the users belong to a group,
and the files are editable by the group because they are rwx by group
members.

So write your own "git-lock" command that does "chmod g-w $@";
git-unlock reenables the group-writable bit. Done.

For more arcane things, use ACLs. On Windows I am sure there is a
commandline tool to touch ACL bits.

hth,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: Interest in locking mechanism?

[Edward Z. Yang]

Excerpts from Martin Langhoff's message of Tue Jan 12 14:33:18 -0500 2010:
> So write your own "git-lock" command that does "chmod g-w $@";
> git-unlock reenables the group-writable bit. Done.

That was what I was thinking of doing (with modestly more cleverness for
recursive operation), and maybe some convenience flags for git-commit
for automatically unlocking or preserving the lock across a commit.

Cheers,
Edward

Re: Interest in locking mechanism?

[Avery Pennarun]

On Tue, Jan 12, 2010 at 2:33 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> On Tue, Jan 12, 2010 at 8:24 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> really).  Just make a 'co' command that writes your username to
>> .filename.lock and chmods the file; then write a ci command that
>> checks the lockfile to make sure it's yours, deletes the lock file,
>> git commits it, and chmods the file back again.
>
> Actually -- on the same track but even better: if you are using a
> unixy system, you are likely to have all the users belong to a group,
> and the files are editable by the group because they are rwx by group
> members.
>
> So write your own "git-lock" command that does "chmod g-w $@";
> git-unlock reenables the group-writable bit. Done.

The trick is to track which user has the file checked out; you don't
want some random person to (accidentally) check in someone else's
file.  That's the whole point.  Of course, you can arrange for this
with some simple shell scripting.

I doubt ACLs are needed really.  RCS certainly works(1) fine without them.

Have fun,

Avery

(1) depending on your definition of "works"

Re: Interest in locking mechanism?

[Martin Langhoff]

On Tue, Jan 12, 2010 at 8:11 PM, Edward Z. Yang <ezyang@mit.edu> wrote:
> I would like to respectfully disagree.  I want to use git because:

I have to say, Avery's got a very good point, and my position (as a
cross SCM user) is that he's right. But I have two suggestions that
might work to at least try out what you say you want...:

 - Write a wrapper around your editor invokation to call `flock $EDITOR $@`

 - Use rcs on top of git, just for the locking -- write a commit hook
that auto-commits to rcs when you commit to git; add suitable excludes
so git doesn't worry about ,v files.

And a comment on your points -

>    * I use Git on a regular basis, and do not use RCS.  I constantly
>      have to go digging through the manpages when I occasionally do
>      stumble upon an RCS system.  Interface familiarity is nice.

that's very weak. Write your our wrappers that mimic git commands you
want to use...

>    * Putting it in Git means that you can easily grow; you can decide
>      "Hey, maybe we want to do branchy development" and just do it,
>      rather than have to drum up the activation energy to do an
>      rcsimport

"Drum up the energy" is somewhat exaggerated ;-)

>    * If code is deployed in a production context as a Git checkout,

If that's what you are doing (or will be doing), just drop rcs, and
explore workflows that help bring attention to any case where there
were edits on the same file.

Actually -- you can focus on workflows that prevent or highlight cases
where the same file is "being edited" in a pre-commit hook that checks
and warns...

 - if new commits (on the matching branch) touch the file (evil: will
have to do git-fetch)

 - if the file was committed recently by a different committer

 - if we're committing a merge involving files changing on more than
one of the heads involved (this case can sometimes be auto-merged with
a diff3-like algorythm)

maybe something on that track helps



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff