Evolve with named branches vs Evolve with topic branches

Faheem Mitha faheem at faheem.info
Mon Mar 11 18:57:14 UTC 2019


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


More information about the Mercurial mailing list