File Locking

[Arne Babenhauserheide]

Am Donnerstag 16 Oktober 2008 22:38:23 schrieb Alpár Jüttner:
> > That's only true when you judge DVCS while thinking in the centralized
> > paradigm.
>
> ?

Means: If you think about "we have one central repo" and "commit = publish" 
then locking seems impossible. 

> Yes, this is what makes it impossible to implement a locking mechanism
> in a sensible way.

A simple way: 
- Add a version controlled list of locked files. 
- Create an extension which checks this list and rejects changesets which 
change files in the list. 

That way revisions which are children of a revision which locks some files 
can't change the locked files.

History doesn't need to be linear, as the locks don't need to be. 

To add security, only signed changesets could be checked by the extension, or 
the lock file could be signed. 

> A sensible locking assume a linear revision history. In my
> interpretation, the main purpose of DVC is to separate the process of
> 'commit' from the synchronization of repo's. For this one must introduce
> a non-linear history. At the end of the day, this is a nice thing. If
> you want to have a linear repo, I strongly believe that you had better
> use SVN, it is just much better for this purpose.

But you don't need linear history for file locking. 

You just need to synchronize your history. 

So you can get the full capabilities of nonlinear history with strong and 
sensible locking. 

Locking in SVN depends on time. 

In a DVCS locking can just depend on parent revisions, which is 
(approximately) the nonlinear equivalent to time. 

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/20081021/b3bc26e9/attachment.pgp