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

[Daniel Carosone]

On Thu, Sep 07, 2006 at 05:51:42PM -0700, Nathaniel Smith wrote:
> The system does have built in a way to resolve the fork, though --
> users pick whichever side they prefer, and update their trust seed to
> point to that.  The fork turns into two independent projects.

A minor wording nit that leads to a major important point.

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.

And no, *twitch*, I'm really *twitch* not bitter. :-)

--
Dan.

pgp3vrfwwMKeq.pgp
Description: PGP signature