On Tue, Jan 12, 2010 at 2:11 PM, Edward Z. Yang <ezyang@xxxxxxx> 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 -- 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