Help designing the evolve UI

[Sean Farley]

Angel Ezquerra <angel.ezquerra at gmail.com> writes:

> On Sat, Apr 19, 2014 at 1:31 AM, Sean Farley
> <sean.michael.farley at gmail.com> wrote:
>>
>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>>
>> [...]
>>
>>>>> I did suggest that being able to see which revisions amend only the
>>>>> metadata would improve things quite a lot, so I guess that we agree,
>>>>> more or less. That being said I don't see what is wrong with wanting
>>>>> to be able to get rid of a local obsolete revision.
>>>>
>>>> What is wrong with it is that it's extremely dangerous and
>>>> non-DVCS-like. There hasn't been a valid reason presented to justify
>>>> stripping obsolete markers. Improving the DAG legibility is worthwhile
>>>> but can and should be done without even thinking about the need to strip
>>>> obsolete markers.
>>>
>>> Sorry, I don't understand why it is so dangerous (and even less why it
>>> is not DVCS-like) to get rid of a _local_, _unshared_ obsolete
>>> revision. It does not seem any more dangerous than striping a regular
>>> revision, is it?
>>
>> I think there is some confusion here. You can strip an obsolete
>> changeset currently but not an obsolete marker.
>
> I knew that you can strip a hidden changeset, but as I asked on a
> previous email I didn't know if that really does the right thing with
> regards to the operation of the obsolete mechanism.
>
>> An obsolete marker is (currently) just a list of the form:
>>
>> OLD_NODE [OPTIONAL NEW_NODE] FLAGS {dictionary of user, date, and parent node}
>>
>>> It is not all that clear to me when obsolete revisions are pushed to a server:
>>
>> They are _never_ pushed to the server. If you want to strip the obsolete
>> *changeset*, then fine. Removing the marker is what should not be allowed.
>
> OK, thanks for the clarification.
>
> I'm starting to think that perhaps, as you said, I'm looking at this wrong.

:-)

> Through this whole thread I've been trying to express a certain
> feeling of loss of control and of unnecessary complexity that I get
> when using evolve. I don't like that it may seem that I'm being a bit
> contrarian or even a luddite but I really am not trying to be. I just
> hope that some of these comments help make the final version of evolve
> a little better.
>
> Let me give you an example of a scenario I faced not long ago:
>
> - Implement a new function and commit it (revision A).
> - Thinking about it maybe I could implement the whole thing in a
> different way? Let's experiment a bit and use this cool evolve
> extension at the same time :-)
> - Change the implementation and amend the previous commit (this
> creates revision B along with a new "temporary amend commit").
> - Ummm, this new implementation is a bit more complicated than I
> expected. I think I prefer the original one. How do I unobsolete it?
>
> My first instinct was to just strip revision B. I would lose some
> history but I didn't find that history very useful (and strip creates
> a backup bundle anyway). However I don't think that would work because
> A would still be obsolete? Also we are now in this "new world" were
> history is append only again, so I should not use strip (unless strip
> becomes obsolete aware perhaps?) :-)
>
> OK, I think the suggested evolve workflow would be to touch the
> original revision... (surely I should not touch the temporary amend
> commit, or should I?):
>
> - OK, let's touch the original revision. Doing so creates a new
> revision C and makes revision B divergent.
> - I think I need to solve the divergence by doing "hg evolve"... Ummm,
> that did not work (abort, "nothing changed").
> - Ah! I think that I need to update to the new touched revision (which
> has a new revision id and revision number, but thankfully I am using
> TortoiseHg).
> - Execute "hg evolve" again. Nice, that worked. This has created a new
> revision D (with its own "temporary amend commit").
>
> So to get back to the original state (before the experiment) I end up
> with 5 new hidden revisions and I need to use three mercurial
> commands, one of which is "hg evolve" which in my experience (on
> windows) is not (yet) super reliable. Is that the simplest way to
> unobsolete the original revision?
>
> The official position seems to be that I should not care about the
> extra hidden commits, but if we want for users to be able to ever use
> the safety net that evolve provides I think the hidden history should
> be as usable as possible, and 5 extra commits for a single failed
> experiment is perhaps a bit too much. Perhaps the log viewer could be
> improved to detect these cases but it would be best if the workflow
> led to less hidden commits in the first place.
>
> Also, the workflow itself feels quite convoluted. It would be nicer to
> have a "revive" of command which would just mark revision B as
> obsolete and create a new revision C that is not divergent (and update
> you to it), or, perhaps even create a new marker and just directly
> revive revision A without creating a new one?
>
> Anyway, I hope this little example either lets you show me that there
> is a better way to do this or at least gives you guys a concrete
> example of why I feel that sometimes it is just easier to use MQ or
> some other unsafe history editing operation.

Thanks for explaining the precise workflow, hopefully we'll be able to
incorporate in on the wiki.

Your experience is definitely a good argument for improving and
polishing the evolve ui. Hopefully soon, this temporary commit will go
away soon since it is just an implementation detail. That will go a long
ways with helping to improve navigating hidden changesets.

Though, I hope it's more or less clear that strip isn't needed at this
point.