New user guide for evolve

Angel Ezquerra angel.ezquerra at gmail.com
Sun Apr 27 21:38:24 UTC 2014


On Sun, Apr 27, 2014 at 10:39 PM, Greg Ward <greg at gerg.ca> wrote:
> On 27 April 2014, Angel Ezquerra said:
>> > However, it's important to understand that new changesets are in the
>> > *draft* phase: they are mutable. This means that they can be modified
>> > by Mercurial's existing history-editing commands (``rebase``,
>> > ``histedit``, etc.), and also by ``evolve``. Generally speaking,
>> > changesets remain in *draft* phase until they are pushed to another
>> > repository, at which point they enter *public* phase. ::
>>
>> Perhaps it is too early in the guide to say so, but maybe we should
>> explicitly say "until they are pushed to another publishing
>> repository"?
>
> Thanks! I think you're right that it's a good idea to at least mention
> publishing vs. non-publishing repos. I added a paragraph that does
> that with a link to the not-yet-written "Sharing Mutable History" doc.
>
>   http://hg.gerg.ca/mutable-history/rev/cd55ce11a17a
>
> Speaking of which: can anyone suggest good use cases to motivate
> sharing mutable history? The "Alice and Bob collaborate on mutable
> changesets" scenario is interesting, but IMHO it's super-advanced.
> Perhaps a more useful and realistic scenario is a single developer
> moving stuff back and forth between two computers. (One is nearby and
> has good merge tools; the other is far away, only accessible via SSH,
> but is setup similar to the production environment, so essential for
> testing before final push.) Certainly that's how I use shared mutable
> history, and I find it extremely useful. I suspect I am not alone.

The Alice and Bob scenario is advanced but important, so IMHO it
should be at least mentioned.
Another perhaps less advanced scenario would be to use mercurial in a
"dropbox-like" manner. In fact a lot of people at my work already do
this without using evolve. They just have to manually strip the
revisions when they have to. Let me explain:

At work we often work on several machines (e.g. the development PC and
a much more powerful compilation server or a PC on the lab). People
often push / pull between their different machines and they continue
working were they left when they move to another machine. They often
need to strip the "obsolete" revisions and they usually even need to
turn them draft first (since not many know about non publising repos).
So I think this is an important and probably common use case.

>> > This creates a new changeset, revision 18, which is a child of
>> > revision 17. And lurking in the background, we still have to worry
>> > about unstable revision 16, which was destabilized by amending
>> > revision 15 with ``hg uncommit``::
>> >
>> >   [figure UG9: rev 15 obsolete, rev 16 unstable, rev 17 and 18 normal]
>> >
>> > This is where things get complicated.
>>
>> Is this really that complicated? It feels obvious that you created a
>> new head in doing this.
>
> Well, *I* was a bit surprised at first, and I'm no Mercurial newbie.
> Once I thought it through and ran "hg --hidden log --graph" in various
> scenarios, I got it. But it was not immediate. So the documentation
> tries to walk the reader through the process I had to go through to
> get it.

I guess it was your excellent write up which made me understand it and
feel that it was not that complicated them.
In any case perhaps we should avoid _telling_ the user that it is
complicated? Let them reach that conclusion if they must. Unless you
think we should "pull a git" and let people feel proud that they
mastered the complexity of the tool on their own? :->

Cheers,

Angel



More information about the Evolve-testers mailing list