Interest in locking mechanism?

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

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

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

Excerpts from B Smith-Mannschott's message of Tue Jan 12 13:29:41 -0500 2010:

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

On 01/12/2010 07:29 PM, B Smith-Mannschott wrote:

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

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

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

Excerpts from Avery Pennarun's message of Tue Jan 12 14:01:42 -0500 2010:

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

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

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

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.

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

On Tue, Jan 12, 2010 at 8:24 PM, Avery Pennarun <apenwarr@gmail.com> wrote:

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

Excerpts from Martin Langhoff's message of Tue Jan 12 14:33:18 -0500 2010:

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

On Tue, Jan 12, 2010 at 2:33 PM, Martin Langhoff <martin.langhoff@gmail.com> wrote:

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"

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

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 -

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

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

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