{"thread":{"id":"22183","subject":"Interest in locking mechanism?","startedAt":"2010-01-12T18:10:10Z","lastAt":"2010-01-12T20:25:18Z","messageCount":11,"participants":["Edward Z. Yang","B Smith-Mannschott","Tomas Carnecky","Avery Pennarun","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"131395","messageId":"1263319565-sup-1767@ezyang","threadId":"22183","inReplyTo":null,"subject":"Interest in locking mechanism?","fromName":"Edward Z. Yang","fromEmail":"ezyang@mit.edu","sentAt":"2010-01-12T18:10:10Z","receivedAt":"2010-01-12T18:10:10Z","isPatch":false,"sender":{"key":"ezyang@mit.edu","avatar":"https://gravatar.com/avatar/6aaa9d10a82c2cf3d676f1f9397c2ae05ee2534182eda446128c0fe7c04494ba?d=mp&s=160"},"body":"I have a few friends that still use RCS for their version control\nneeds.  We have argued over various points between RCS and Git, and\nas far as I can tell the one thing RCS has that Git does not is\na locking mechanism.  That is to say, co -l checks out a file and\nalso gives you a lock on it, preventing others from futzing with it,\nand ci -u checks in the file and releases your lock.  This is\nuseful if you have a shared working copy on a multiuser system or\non a network file system, and you don't want conflicts.\n\nI was wondering if there would be interest in such a feature on\nthe Git developers side.\n\nCheers,\nEdward\n"},{"id":"131397","messageId":"28c656e21001121029h42544f3er6eedf8465851fec1@mail.gmail.com","threadId":"22183","inReplyTo":"1263319565-sup-1767@ezyang","subject":"Re: Interest in locking mechanism?","fromName":"B Smith-Mannschott","fromEmail":"bsmith.occs@gmail.com","sentAt":"2010-01-12T18:29:41Z","receivedAt":"2010-01-12T18:29:41Z","isPatch":false,"sender":{"key":"bsmith.occs@gmail.com","avatar":"https://gravatar.com/avatar/46449e07c27bb8a30e4d50c08859f7210d47f6e84526b0a3b903641231dfc1bd?d=mp&s=160"},"body":"On Tue, Jan 12, 2010 at 19:10, Edward Z. Yang <ezyang@mit.edu> wrote:\n> I have a few friends that still use RCS for their version control\n> needs.  We have argued over various points between RCS and Git, and\n> as far as I can tell the one thing RCS has that Git does not is\n> a locking mechanism.  That is to say, co -l checks out a file and\n> also gives you a lock on it, preventing others from futzing with it,\n> and ci -u checks in the file and releases your lock.  This is\n> useful if you have a shared working copy on a multiuser system or\n> on a network file system, and you don't want conflicts.\n>\n> I was wondering if there would be interest in such a feature on\n> the Git developers side.\n\nHow do you imagine that this would work in a distributed system such\nas git? What would it mean to have the lock for \"a file\", when each\nuser effectively has their own branch?\n\n// Ben\n"},{"id":"131399","messageId":"1263321111-sup-4827@ezyang","threadId":"22183","inReplyTo":"28c656e21001121029h42544f3er6eedf8465851fec1@mail.gmail.com","subject":"Re: Interest in locking mechanism?","fromName":"Edward Z. Yang","fromEmail":"ezyang@mit.edu","sentAt":"2010-01-12T18:33:49Z","receivedAt":"2010-01-12T18:33:49Z","isPatch":false,"sender":{"key":"ezyang@mit.edu","avatar":"https://gravatar.com/avatar/6aaa9d10a82c2cf3d676f1f9397c2ae05ee2534182eda446128c0fe7c04494ba?d=mp&s=160"},"body":"Excerpts from B Smith-Mannschott's message of Tue Jan 12 13:29:41 -0500 2010:\n> How do you imagine that this would work in a distributed system such\n> as git? What would it mean to have the lock for \"a file\", when each\n> user effectively has their own branch?\n\nHi Ben,\n\nGood question.  I don't intend for the locking mechanism to leak into\nthe distributed model of Git. It is solely for working copies, which /are/\ncentralized (just there can be a lot of them), when multiple people might\nbe editing the same working copy.\n\nThere is a somewhat natural question of: well, you should clone, make your\nchanges in your own copy, and then push them back.  That is arguably the\ncorrect mechanism.  However, for casual users batonning changes from one\nrepository to another is often more overhead than is really necessary, and\nI think a working copy locking mechanism will help for simple cases.\n\nCheers,\nEdward\n"},{"id":"131398","messageId":"4B4CC17B.30303@dbservice.com","threadId":"22183","inReplyTo":"28c656e21001121029h42544f3er6eedf8465851fec1@mail.gmail.com","subject":"Re: Interest in locking mechanism?","fromName":"Tomas Carnecky","fromEmail":"tom@dbservice.com","sentAt":"2010-01-12T18:37:47Z","receivedAt":"2010-01-12T18:37:47Z","isPatch":false,"sender":{"key":"tom@dbservice.com","avatar":"https://gravatar.com/avatar/900a300bdd1a8bbe086008ad78210bbee2ad2803b7d50a5cba04c1e9404bd6d2?d=mp&s=160"},"body":"On 01/12/2010 07:29 PM, B Smith-Mannschott wrote:\n> On Tue, Jan 12, 2010 at 19:10, Edward Z. Yang<ezyang@mit.edu>  wrote:\n>> I have a few friends that still use RCS for their version control\n>> needs.  We have argued over various points between RCS and Git, and\n>> as far as I can tell the one thing RCS has that Git does not is\n>> a locking mechanism.  That is to say, co -l checks out a file and\n>> also gives you a lock on it, preventing others from futzing with it,\n>> and ci -u checks in the file and releases your lock.  This is\n>> useful if you have a shared working copy on a multiuser system or\n>> on a network file system, and you don't want conflicts.\n>>\n>> I was wondering if there would be interest in such a feature on\n>> the Git developers side.\n>\n> How do you imagine that this would work in a distributed system such\n> as git? What would it mean to have the lock for \"a file\", when each\n> user effectively has their own branch?\n\nHe mentioned a shared working copy, in which case there can be problems \nif multiple users edit the same file.\n\nUsually you'd work around that by cloning the repo, working in the \nclone, and push the result back. This can get a bit tricky if the main \nrepository is not bare, but there is a solution even to that (either \nexplicitly run git reset --hard or have a post-receive hook which \nupdates the working tree).\n\ntom\n"},{"id":"131401","messageId":"32541b131001121101i76ad8062p3a7f3571ad86b0ce@mail.gmail.com","threadId":"22183","inReplyTo":"1263319565-sup-1767@ezyang","subject":"Re: Interest in locking mechanism?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-01-12T19:01:42Z","receivedAt":"2010-01-12T19:01:42Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Jan 12, 2010 at 1:10 PM, Edward Z. Yang <ezyang@mit.edu> wrote:\n> I have a few friends that still use RCS for their version control\n> needs.  We have argued over various points between RCS and Git, and\n> as far as I can tell the one thing RCS has that Git does not is\n> a locking mechanism.  That is to say, co -l checks out a file and\n> also gives you a lock on it, preventing others from futzing with it,\n> and ci -u checks in the file and releases your lock.  This is\n> useful if you have a shared working copy on a multiuser system or\n> on a network file system, and you don't want conflicts.\n\nIf what you want is just one shared working copy with locking, then\nwhat you want is RCS.  Why change what's not broken?  You're not doing\nanything distributed or even any branching, and you don't need to\natomically commit multiple files at once (which would be very\nconfusing if more than one person is changing stuff in the current\ntree), so git doesn't seem buy you anything.\n\nThere are lots of arguments that the central-shared-copy-with-locking\nis obsolete.  It's been obsolete since at least CVS (the \"concurrent\nversions system\", named after the fact that you didn't have to have\none central working copy).  But if you don't agree that this model is\nobsolete, you might as well use a tool that treats your use case as a\nfirst class citizen.\n\nHave fun,\n\nAvery\n"},{"id":"131402","messageId":"1263323292-sup-4182@ezyang","threadId":"22183","inReplyTo":"32541b131001121101i76ad8062p3a7f3571ad86b0ce@mail.gmail.com","subject":"Re: Interest in locking mechanism?","fromName":"Edward Z. Yang","fromEmail":"ezyang@mit.edu","sentAt":"2010-01-12T19:11:44Z","receivedAt":"2010-01-12T19:11:44Z","isPatch":false,"sender":{"key":"ezyang@mit.edu","avatar":"https://gravatar.com/avatar/6aaa9d10a82c2cf3d676f1f9397c2ae05ee2534182eda446128c0fe7c04494ba?d=mp&s=160"},"body":"Excerpts from Avery Pennarun's message of Tue Jan 12 14:01:42 -0500 2010:\n> If what you want is just one shared working copy with locking, then\n> what you want is RCS.  Why change what's not broken?  You're not doing\n> anything distributed or even any branching, and you don't need to\n> atomically commit multiple files at once (which would be very\n> confusing if more than one person is changing stuff in the current\n> tree), so git doesn't seem buy you anything.\n\nI would like to respectfully disagree.  I want to use git because:\n\n    * I use Git on a regular basis, and do not use RCS.  I constantly\n      have to go digging through the manpages when I occasionally do\n      stumble upon an RCS system.  Interface familiarity is nice.\n\n    * Putting it in Git means that you can easily grow; you can decide\n      \"Hey, maybe we want to do branchy development\" and just do it,\n      rather than have to drum up the activation energy to do an\n      rcsimport.\n\n    * If code is deployed in a production context as a Git checkout,\n      you can definitely have both branchy development as well as\n      a shared working copy (with low contention, but contention nonetheless).\n\nCheers,\nEdward\n"},{"id":"131403","messageId":"32541b131001121124u541de280na9184183d8704dc8@mail.gmail.com","threadId":"22183","inReplyTo":"1263323292-sup-4182@ezyang","subject":"Re: Interest in locking mechanism?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-01-12T19:24:52Z","receivedAt":"2010-01-12T19:24:52Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Jan 12, 2010 at 2:11 PM, Edward Z. Yang <ezyang@mit.edu> wrote:\n>    * I use Git on a regular basis, and do not use RCS.  I constantly\n>      have to go digging through the manpages when I occasionally do\n>      stumble upon an RCS system.  Interface familiarity is nice.\n\nBut the users who are arguing in favour RCS would say the opposite, right?\n\n>    * Putting it in Git means that you can easily grow; you can decide\n>      \"Hey, maybe we want to do branchy development\" and just do it,\n>      rather than have to drum up the activation energy to do an\n>      rcsimport.\n\nBut then you'd have to do an import now instead of later, for no\nimmediate gain.  The extreme programming people would say YAGNI here;\ndelay the work until it's actually required, because it'll be no more\nwork later than it is right now.\n\n>    * If code is deployed in a production context as a Git checkout,\n>      you can definitely have both branchy development as well as\n>      a shared working copy (with low contention, but contention nonetheless).\n\nI would suggest that by the time you're doing this, you're just lying\nto yourself if you think you have RCS-style locking.  People will\nquite easy be able to change the same files as other people, then push\ninto git, and sooner or later someone will have to pull from git into\nthe original shared repository, possibly stomping on other people's\nwork.  So you end up not having the advantage you were trying to\nachieve.\n\nBTW, I will try be a bit more constructive in case you *really* want\nthis: I've never heard of anyone doing RCS-style locking with git, so\nyou're probably out of luck if you're looking for a pre-made solution.\n But it's probably rather easy to construct a simple shell script\nimplementation that's independent of your revision control system\n(since locking files has nothing to do with revision tracking,\nreally).  Just make a 'co' command that writes your username to\n.filename.lock and chmods the file; then write a ci command that\nchecks the lockfile to make sure it's yours, deletes the lock file,\ngit commits it, and chmods the file back again.\n\nHave fun,\n\nAvery\n"},{"id":"131404","messageId":"46a038f91001121126t6b2bdd36vfe5ed44291644ab9@mail.gmail.com","threadId":"22183","inReplyTo":"1263323292-sup-4182@ezyang","subject":"Re: Interest in locking mechanism?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2010-01-12T19:26:59Z","receivedAt":"2010-01-12T19:26:59Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Tue, Jan 12, 2010 at 8:11 PM, Edward Z. Yang <ezyang@mit.edu> wrote:\n> I would like to respectfully disagree.  I want to use git because:\n\nI have to say, Avery's got a very good point, and my position (as a\ncross SCM user) is that he's right. But I have two suggestions that\nmight work to at least try out what you say you want...:\n\n - Write a wrapper around your editor invokation to call `flock $EDITOR $@`\n\n - Use rcs on top of git, just for the locking -- write a commit hook\nthat auto-commits to rcs when you commit to git; add suitable excludes\nso git doesn't worry about ,v files.\n\nAnd a comment on your points -\n\n>    * I use Git on a regular basis, and do not use RCS.  I constantly\n>      have to go digging through the manpages when I occasionally do\n>      stumble upon an RCS system.  Interface familiarity is nice.\n\nthat's very weak. Write your our wrappers that mimic git commands you\nwant to use...\n\n>    * Putting it in Git means that you can easily grow; you can decide\n>      \"Hey, maybe we want to do branchy development\" and just do it,\n>      rather than have to drum up the activation energy to do an\n>      rcsimport\n\n\"Drum up the energy\" is somewhat exaggerated ;-)\n\n>    * If code is deployed in a production context as a Git checkout,\n\nIf that's what you are doing (or will be doing), just drop rcs, and\nexplore workflows that help bring attention to any case where there\nwere edits on the same file.\n\nActually -- you can focus on workflows that prevent or highlight cases\nwhere the same file is \"being edited\" in a pre-commit hook that checks\nand warns...\n\n - if new commits (on the matching branch) touch the file (evil: will\nhave to do git-fetch)\n\n - if the file was committed recently by a different committer\n\n - if we're committing a merge involving files changing on more than\none of the heads involved (this case can sometimes be auto-merged with\na diff3-like algorythm)\n\nmaybe something on that track helps\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"131405","messageId":"46a038f91001121133r62b3d748n38ca27234f18e960@mail.gmail.com","threadId":"22183","inReplyTo":"32541b131001121124u541de280na9184183d8704dc8@mail.gmail.com","subject":"Re: Interest in locking mechanism?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2010-01-12T19:33:18Z","receivedAt":"2010-01-12T19:33:18Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Tue, Jan 12, 2010 at 8:24 PM, Avery Pennarun <apenwarr@gmail.com> wrote:\n> really).  Just make a 'co' command that writes your username to\n> .filename.lock and chmods the file; then write a ci command that\n> checks the lockfile to make sure it's yours, deletes the lock file,\n> git commits it, and chmods the file back again.\n\nActually -- on the same track but even better: if you are using a\nunixy system, you are likely to have all the users belong to a group,\nand the files are editable by the group because they are rwx by group\nmembers.\n\nSo write your own \"git-lock\" command that does \"chmod g-w $@\";\ngit-unlock reenables the group-writable bit. Done.\n\nFor more arcane things, use ACLs. On Windows I am sure there is a\ncommandline tool to touch ACL bits.\n\nhth,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"131406","messageId":"1263325308-sup-5516@ezyang","threadId":"22183","inReplyTo":"46a038f91001121133r62b3d748n38ca27234f18e960@mail.gmail.com","subject":"Re: Interest in locking mechanism?","fromName":"Edward Z. Yang","fromEmail":"ezyang@mit.edu","sentAt":"2010-01-12T19:43:19Z","receivedAt":"2010-01-12T19:43:19Z","isPatch":false,"sender":{"key":"ezyang@mit.edu","avatar":"https://gravatar.com/avatar/6aaa9d10a82c2cf3d676f1f9397c2ae05ee2534182eda446128c0fe7c04494ba?d=mp&s=160"},"body":"Excerpts from Martin Langhoff's message of Tue Jan 12 14:33:18 -0500 2010:\n> So write your own \"git-lock\" command that does \"chmod g-w $@\";\n> git-unlock reenables the group-writable bit. Done.\n\nThat was what I was thinking of doing (with modestly more cleverness for\nrecursive operation), and maybe some convenience flags for git-commit\nfor automatically unlocking or preserving the lock across a commit.\n\nCheers,\nEdward\n"},{"id":"131408","messageId":"32541b131001121225y3929d6cao437297f4f233f4e@mail.gmail.com","threadId":"22183","inReplyTo":"46a038f91001121133r62b3d748n38ca27234f18e960@mail.gmail.com","subject":"Re: Interest in locking mechanism?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-01-12T20:25:18Z","receivedAt":"2010-01-12T20:25:18Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Jan 12, 2010 at 2:33 PM, Martin Langhoff\n<martin.langhoff@gmail.com> wrote:\n> On Tue, Jan 12, 2010 at 8:24 PM, Avery Pennarun <apenwarr@gmail.com> wrote:\n>> really).  Just make a 'co' command that writes your username to\n>> .filename.lock and chmods the file; then write a ci command that\n>> checks the lockfile to make sure it's yours, deletes the lock file,\n>> git commits it, and chmods the file back again.\n>\n> Actually -- on the same track but even better: if you are using a\n> unixy system, you are likely to have all the users belong to a group,\n> and the files are editable by the group because they are rwx by group\n> members.\n>\n> So write your own \"git-lock\" command that does \"chmod g-w $@\";\n> git-unlock reenables the group-writable bit. Done.\n\nThe trick is to track which user has the file checked out; you don't\nwant some random person to (accidentally) check in someone else's\nfile.  That's the whole point.  Of course, you can arrange for this\nwith some simple shell scripting.\n\nI doubt ACLs are needed really.  RCS certainly works(1) fine without them.\n\nHave fun,\n\nAvery\n\n(1) depending on your definition of \"works\"\n"}]}