On 01/12/2010 07:29 PM, B Smith-Mannschott wrote:
On Tue, Jan 12, 2010 at 19:10, Edward Z. Yang<ezyang@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html