New user guide for evolve

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri May 2 22:57:28 UTC 2014



On 04/27/2014 02:38 PM, Angel Ezquerra wrote:
> 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.

In my opinion, The simplest and most selling example for exchanging 
mutable history is: code review

sharing mutable history let:
- Alice to push unfinished changeset to Bob eyes without fear.
- Alice to push new version of such changeset without mess (the old one 
disappear from Alice repo, from Bob repo etc). Not even a push --force 
is needed
- Bob can make minor fix/rebasing before publishing the patches. Alice 
repo will be properly fixed when she pull the accepted version

-- 
Pierre-Yves



More information about the Evolve-testers mailing list