Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction

[Nathaniel Smith]

On Fri, Sep 08, 2006 at 11:26:32AM +1000, Daniel Carosone wrote:
> Two projects, but 'independent' (which you meant in terms of
> administration and trust seeds) should not imply other kinds of
> independence that are undesirable, even in the face of a fork.
> 
> The projects share common technical history.  With monotone, unlike
> *any* other VCS I'm aware of, even if there is absolute and complete
> administrative distrust between the administrations of each project,
> there is no reason for them to break this history to achieve this
> independance.  They might choose to selectively trust or distrust
> certain revisions, probably around the time leading up to the fork and
> maybe even related to the issue under contention, but there's now no
> direct harm either project can do to the other on the basis of the
> common VCS tool with common history.
> 
> So, some time later when things might have cooled off a little,
> various fixes and features developed on either side of the fork can be
> brought across the gap with the full benefit of the tool.  A third
> fork might even start up trying to take the best of both, or to
> reintegrate the projects.
> 
> This is sufficiently valuable, rare and important that we should make
> it a clear use case and documentation example going forward.  It's not
> that monotone necessarily encourages projects to fork, rather that the
> tool continues to work no matter how stupid, divisive and pigheaded
> certain people might choose to be.

This is a nice property, and it'd be cool to be able to use it as a
selling point, but I'm actually not sure that it's at all unique.  The
approach that most DVCSes use for trust etc. is to make each and every
person and branch its own trust domain: a complete fork, effectively.
The problem for them is building a coherent community as a layer on
top of these scattered trusts.  The result is that their tools treat
two people who don't talk to each other in exactly the same way it
treats two people who do talk to each other, so merging etc. between
projects should work fine.

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."