File Locking

[Arne Babenhauserheide]

Am Mittwoch 08 Oktober 2008 04:29:42 schrieb Michael Smith:
> The whole project consists of models. Currently it is all in MS VSS
> which provides locking. I started to use HG because they also needed to
> share data over a WAN. In that environment locking doesn't work well
> enough regardless of the tool you are using.

How about just not allowing people to create remote heads? 

That's something similar to locking: 
"If someone else pushed changes before you, 
. pull his changes, then 
- look at his file and at your file,
- update your file accordingly, 
- commit your updated file and then 
- merge his commit." 

Technically: 

hg push gives the error "creates new remote heads": 

hg pull
hg heads # just get the information about the heads

(open your version of the file)
hg update the_other_head
(open the other version of the file)
hg merge -> just select one version of the file. 
(edit and save the file to include both changes)
hg commit -m "Included changes from the_other_head" # commit the merge. 

hg push


That's gives the same as 

svn commit -m "Conflicting commit"
-> merge conflict!

svn up
(open your version)
svn revert conflicting_file
(open the other version)
(edit and save one of the versions to include both changes)

svn commit -m "Included changes from the_other_head"

But the hg version has the huge advantage, that the new changes done by you 
have already been saved in a commit, so they can't as easily get lost. If you 
don't allow remote heads, they can't pollute others repositories, but if the 
dev doesn't have time to merge right now, the changes will still be there the 
next day. 

He can even leave them dangling as head (as long as he doesn't push) and pull 
again later and only merge once he has time. 

The three additional steps in hg are necessary, to allow local commits. And 
one of the steps is simply "hg heads" - an information request. The others are 
explicitly switching between your and the other version (stronger then svn 
revert) and explicitely merging the heads to have linear history again. 

So, you effectively get file locking in the shared repository if you disallow 
creating remote heads, but with the advantage that the developers can commit 
their work without locking problems - if you lock a svn repository, the 
developers will still work locally without locking (or won't be able to do any 
work at all for some time), but the commit won't work and there will be the 
danger of losing good work (possible problems with reverting and subsequent 
saving - some programs do auto updates on externally changed files). 

Best wishes, 
Arne
-- 
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20081008/3046c9dc/attachment.pgp