current state of evolve vs core in 3.7.3

Bryan Murdock bmurdock at gmail.com
Wed Jun 29 19:00:25 UTC 2016


On Tue, Jun 28, 2016 at 1:58 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2016-06-28 at 11:53 -0700, Lee Nave wrote:
>> There are these warnings in the docs:
>>
>> "Using this EvolveExtension will alter some of the core commands and
>> behaviors."
>>
>> "The evolve extension enables the ChangesetEvolution feature, changing some
>> of Mercurial's default behavior.
>>
>>    history rewriting commands do not strip changesets anymore; they make
>> them obsolete.
>>    history rewriting commands will work on any changesets, possibly
>> creating unstable changesets.
>>    pull and push exchange obsolescence data with other evolve-enabled
>> repositories - this may have a performance impact!"
>>
>> We are upgrading our server from 2.7 to 3.7.3 and I'm wondering if these
>> warnings still apply.  It is not clear to me what in the evolve extension
>> is not already in 3.7.3 core and if those things are not considered
>> production-ready.
>
> All of the warnings still apply.
>
> Some of the mechanisms are in core, most of the ui is not. It is certainly
> possible for individual developers ("power users") to use evolve locally in just
> about any development environment (for instance, there are many evolve users at
> Facebook), but it's still fragile enough that I wouldn't yet make it a mandatory
> part of the workflow/infrastructure for any team of more than a handful of
> people.

If you have a couple people that are comfortable with evolve I'd say
go for it.  Maybe I'm too cavalier, but at my last job (I left just a
few months ago) when I migrated the team (roughly 30 people) from svn
to mercurial about a year ago I enabled evolve for everyone on the
team.  I was very comfortable with mercurial and evolve when I did it.
Rebase and amend were parts of our standard flow and people did fine.
I wrote a document that explained other operations such as fold and
prune.  I don't know how many people ever tried those, but we didn't
have any major problems (aside from normal svn to mercurial confusion
like, "I have to push after I commit!?").

One of my motivations for pushing evolve on everyone was because of my
mercurial experience with a previous team.  We started with just
straight mercurial, but somehow someone discovered mq and it really
caught on.  People loved the power, but they got themselves into some
messes where they lost work.  Doing similar operations with evolve
("refreshing" a commit with amend, rebasing, folding commits together,
etc.) you *never* lose work.  The original commits are always still
there, just hidden.

At my new job everyone is getting used to git (coming from svn and/or
clearcase) and we've had people end up in much stranger states than
I've ever seen with mercurial (well, some mq messes were worse because
git, like evolve, is pretty good about not losing work).  I use evolve
extensively (with hg-git now) and 99% of the time it's just fine.  The
one problem I see is that bookmarks get left on obsolete commits after
a fold or prune or something (I haven't paid that much attention to
exactly when it happens).  I just use hg bookmark -f to put the
bookmarks back where they belong when that happens.  I had never used
bookmarks before, but you have to to be compatible with git.

Bryan



More information about the Evolve-testers mailing list