On Evolve creating too many obsolete commits

[Angel Ezquerra]

On Fri, May 2, 2014 at 8:17 PM, Jordi Gutiérrez Hermoso
<jordigh at octave.org> wrote:
> On Fri, 2014-05-02 at 11:08 -0700, Pierre-Yves David wrote:
>> The request here is not about throwing away other people content, but
>> about organising a wall of text into something worthwhile. Please makes
>> it a priority before any further progress on this discussion.
>
> Okay, I'll try, but...
>
>     Il semble que la perfection soit atteinte non quand il n'y a plus
>     rien à ajouter, mais quand il n'y a plus rien à retrancher.
>
> and there is still so much to remove
>
> - Jordi G. H.

I wrote most of that section, including the intermeshed ramblings :-)

One of the reasons why the section is a bit rambling is that as the
days have gone by and as I've been thinking about this my mind has
changed a bit about this subject. So please let me try to recap my
thinking here to see if that can help clarify that section a bit? I
don't promise this explanation will be shorter but at least I hope it
will be clearer...

My _original_ complaint was that using evolve usually results in the
introduction of a lot of obsolete changesets. I thought that was a
problem for several reasons but now I think that this is not a bad
thing per se (if we ignore the potential for greatly increasing the
repository size). The problem is not that there are too many obsolete
revisions, but rather that the way in which they are currently
presented to the user makes using them hard except in the simplest of
cases.

It is my understanding that keeping track of old versions of your
revision history is not really the primary purpose of evolve (which is
making it possible to safely share mutable history). However IMHO it
is (or it should be) an important second objective of evolve. I
believe that this second objective is currently not very well covered
by evolve and that is the whole purpose of that section on the wiki.

The problem is not really that there are too many obsolete revisions
(even though that is what I originally thought). The actual problem is
that even though evolve offers you a way to see all versions of your
changesets, that is a solution to the wrong problem. I am not
interested in the whole set of obsolete revisions. I am interested in
the _states_ that the _whole repository_ went through as I edited its
history.

For example, if in order to get to a final repository state I did 3
history editing actions such as "rebase, fold and amend" I'd like to
be able to ask mercurial to show me the state before and after each of
those 3 operations. The 3 history editing operations could create 20
obsolete changesets, but I wouldn't care about those 20 obsolete
changesets as a whole. I would care about the 3 groups of obsolete
changesets created by each of those 3 history editing operations. It
is as if each of those 3 groups belonged to a separate "edit branch"
or "repository meta-revision".

So my proposal is that evolve should somehow keep track of which
history editing operation created which changesets so that they can
later be grouped in that way. Then I could ask mercurial things such
as "show me the state of the repo right before I did this rebase" or
"which revisions were changed by this rebase and how?", compare the
state of the repo with how it was before I did the last 3 history
editing operations.

A nice side effect of this would be that it could make it easier for
collaborators to understand what changed when their revisions become
obsolete or unstable after another users pushes successors of the
revisions on their repo (e.g. rather than just seeing that "these
revisions are now obsolete" I would see that "these revisions have
been made obsolete because Pierre-Yves rebased them and then folded
them and then amended them").

How could this be done? Maybe the history editing operation could be
saved into extra when creating the successors, or maybe the info could
be saved as an action to revisionid table?

Cheers,

Angel

P.S.- Jordi, a few days ago I watched the evolve presentation that you
did at Pycon in Canada and I loved it. Great job!