Help designing the evolve UI

[Angel Ezquerra]

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.

Cheers and thanks for your patience,

Angel