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
branch.
What do you think?
Gili
More information about the Mercurial
mailing list