obliterate functionality?

cowwoc cowwoc at bbs.darktech.org
Tue Mar 18 13:35:00 CDT 2008

	So let me ask the next obvious question: I can see the value of 
distributing a repository across multiple nodes, but does the value of 
full P2P (ownerless) architecture outweigh its costs in the context of a 
source-code repository? It's not like we're building a music 
file-sharing network here :)

	Couldn't you have a distributed repository with an ownership hierarchy 
which solves this (and other) trust problems? I don't think you'd lose 
any value. It's not as if contemporary code repositories suffer from 
censorship. Aren't we solving a nonexistent problem here?

	I'll give you a concrete example... Say Mercurial let you define a 
parent node (owner) for each repository.

1) Parent node may obliterate on its own code, when you pull changes 
from it you're forced to accept their obliterate (since they own that code).

2) You may obliterate on your local copy but the parent may not 
necessarily give you permission to obliterate on its copy. If you don't 
have permissions a commit will fail. Your local copy will still remain 
obliterated but uncommitted (with respect to the parent node). Children 
nodes could still pull your version (obliterated) if they designate you 
as their parent.

3) Within the scope of the same codebase you could create your own 
branch and designate yourself as the owner. Now what happens is that 
your branch is a delta off the main branch which the parent node owns. 
Now someone could designate you as his parent and pull changes off your 

	What do you think?


More information about the Mercurial mailing list