Re: [Monotone-devel] Comparison of Monotone and git

[Eric Anderson]

Brian May writes:
 > Bruce Stephens wrote:
 > >>  * History rewriting:
 > >>     - Git has an easy UI for re-writing history in a local repository
 > >>       - The re-base command that allows patch sets to be cleaned up
 > >> before submission
 > >>       - There is no reason this couldn't be done in monotone, but it
 > >> goes against the Monotone philosophy.  You'd end up using a bunch of
 > >> mtn kill_rev_locally' style operations that Monotone considers
 > >> dangerous.

kill_rev_locally could be made safe if monotone tracked whether it had
ever pushed a revision to another node.  Provided that hasn't
happened, then doing a local kill is safe (ish) since no one could
have seen the revision.  The (ish) is because a user might be getting
rid of some useful state.

 > Personally I like monotone's model that history, once written, never 
 > changes. It is a permanent record of who did what/when/why. It it meant 
 > to be messy.

The one case where I can see it would be useful is the following:

D 
|\
B C
|/
A

Where A is the parent revision; B and C were done simultaneously by
different developers, and then merged into D.  Lets assume that B
synchronized her changes to a central repo first, and C pulled the
change before synchronizing, but had already committed her changes.
Then you get the state:

(dev1)   (dev2)
B         B C
|         |/
A         A

dev2 has two options.  1) she can merge B and C, or 2) she can create
the A->C diff, kill the C revision locally, and apply the A->C diff,
resulting in:

C
|
B
|
A

I personally would be a fan of getting the latter result as it seems
cleaner and then plays along better with doing bisect like things.
Obviously if either B or C were published, then this linearization
transform isn't safe and the merge should be kept.

Consider the attached revision graph from one of our projects.  Out of
the 35 most recent changes, 11 were merges.  Some of these are
inherent; work was happening on multiple disconnected networks, and so
synchronization was infrequent.  Others could have been safely
linearized.  While this merge rate is slightly high for the overall
project (93 merges, 374 direct decendents) it shows the problem.

I suspect a good result would be for monotone to track when a revision
has not been propagated, and whether the diffs are commutative, and if
both those considitions are satisfied then a linearize operation could
be applied which would remove the merge nodes.  Unfortunately I don't
have time to implement such a feature, so I can only put it out as a
feature request.
        -Eric