On Evolve creating too many obsolete commits

[Colin Caughie]

On 5/3/2014 8:02 AM, Angel Ezquerra wrote:
> 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?
>
Or maybe every history editing operation could just increment some 
sequence number (assuming there's somewhere that such a thing could be 
stored), and that sequence number could be saved as metadata to each 
affected revision? This would be purely informational, so would add 
minimal complexity to the system internals but would allow clients such 
as TortoiseHg to provide visualizations the steps that the history went 
through.

Conceivably a client could even implement some kind of "undo last 
evolve" feature by pruning all of the changesets with sequence number N 
(the most recent one), and touching/resurrecting all those with sequence 
numbers of N - 1.

There are probably flaws in this idea but I thought I'd throw it out there.

Colin