Evolve with named branches vs Evolve with topic branches

Aurélien Campéas aurelien.campeas at pythonian.fr
Tue Mar 12 06:06:39 UTC 2019


Hi Faheem,

I believe the point of topics is to emulate a "feature branch"
workflow familiar to git users (the equivalent of a publication
there would be to rebase over develop or master).

You need not "push to a publishing repo" to drop the topics
(this is a part of the tutorial I disagree with).
Changing the phase with "hg phase" would do it.

This is exactly how I "drop the topics of sufficiently old csets",
e.g. the moment the cat is out of the bag, I mean when I tag a version.

In the current state of topics also, for performance reasons, I
also suspect it is not a good idea to keep them forever.

Regards,
Aurélien.

On 11/03/2019 19:57, Faheem Mitha wrote:
> 
> Hi folks,
> 
> I've been using Evolve for some time. One issue I've noticed is that
> if I've doing a lot of amends over a period of time, to a file or
> files, the rewriting mounts up quickly, because other commits get in
> the way. The other day it occurred to me that a way around this would
> be to do commits on a separate branch. I've mostly stopped using named
> branches in recent years, because they last forever in history, and
> look ugly. But Evolve can obsolete named branches, so it is not so
> much of an issue once one is using Evolve.
> 
> So one can go off and work on some specific file or related group of
> files in peace, without interference from other csets corresponding to
> other files. I initially thought I would just use named branches, but
> was informed that the new topics extension, which is shipped with
> Evolve, is precisely designed for that use case.
> 
> I looked through the topic tutorial and experimented with topics a
> bit. It's very similar to named branches, but with a couple of
> important differences.
> 
> Named branches are purely topological. If I rebase csets from a named
> branch to default, those csets stop having the branch name attached to
> them and become part of default. In contract, if I rebase a topic
> branch to default, the csets from the topic branch keep the same topic
> name, and `hg up topicname` continues to work within default - moving
> one to the "tip" of the topic csets. If one wants to remove the topic
> name, one needs to rewrite it.
> 
> The other obviously important thing is that when the csets are pushed
> to a publishing repository, the topic disappears, without rewriting
> the csets. If the topic csets are in a different topological branch
> from default, the remaining structure appears to be a regular
> anonymous branch.
> 
> I'm not completely clear about the reason for these design decisions.
> 
> It seems the assumption is that topics are inherently draft level
> things, and are not needed once the csets are published/final. And I
> suppose the reason that the topic keywords do not disappear when the
> csets are rebased to default (for example) is that the topic is
> considered as a property of the cset, so to speak.
> 
> However, my current workflow doesn't involve publishing. I currently
> push to a non-publishing repos, and I don't want to change that. But I
> guess I would be open to some automated method for making sufficiently
> old csets public. But I don't know of one right now. And I'd prefer
> not to tie my workflow to publishing.
> 
> In any case, I was wondering if it would be reasonable if I was simply
> to use named branches for this purpose, for the time being, instead of
> topic. At first sight, it looks workable and simpler to me. If I
> rebase the named branch to default, the named branch is obsoleted, and
> one can forget about it. I think this would work for my purposes. But
> is there anything I am missing that makes named branches an unsuitable
> choice for this purpose?
> 
> Thanks in advance for any replies.
> 
> Regards, Faheem Mitha
> _______________________________________________
> Evolve-testers mailing list
> Evolve-testers at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/evolve-testers



More information about the Evolve-testers mailing list