[oe] Reconsidering the work flow and how the SCM system fits in

[Justin Patrin]

On Wed, Mar 12, 2008 at 3:21 PM, Paul Sokolovsky <pmiscml at gmail.com> wrote:
> Hello,
>
>
>  On Wed, 12 Mar 2008 17:03:13 -0500
>  Mike Westerhof <mwester at dls.net> wrote:
>
>  >  On Wed 12/03/08  4:40 PM , Paul Sokolovsky pmiscml at gmail.com sent:
>  > ...
>  > > With mtn we seem to have very cheap and robust mirroring and
>  > > high-availability. Well, any DSCM lean on possibility of easy
>  > > mirroring, but Monotone with its super-cool concept of unbelievably
>  > > cheap branches (so-called heads), ...
>  >
>  > Hehe! Yes, and I could describe an automobile spinning out-of-control
>  > on a patch of ice as "unbelievably cheap steering" just as well.
>  > Let's not overlook the fact that the multiple-heads issue with
>  > monotone is very seldom because the person doing it *wished* for that
>  > to happen.
>
>  Vice-versa, as was noted already, we have separate head created
>  almost on each commit (i.e. mtn merge almost always has something to
>  do on each run after commit). So, can one imagine more lightweight
>  branches - they are being created even without any explicit command!
>  Poor git is left far behind with its heavy branch commands! ;-D
>

And just to add insult to injury, this also points out that mtn also
merges very well, with no extra help. The non-content conflicts which
are trotted out again and again are due more to incorrect use of mtn
(read: not reading documentation) than to any problems in mtn itself.
It really depends on what you want. Reliable, correct, and impeccable
revision history or history through interchange of patches with an
implicit web of trust.

-- 
Justin Patrin