On Tue, 12 Mar 2019, Aurélien Campéas wrote:
Hi Faheem,
Hi Aurélien,
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.
Thank you for the response.
Yes, I realise that changing the phase of csets would suffice - that's
one of the side-effects of pushing to a publishing repos. I was
thinking that maybe I could just run an automated job to periodically
make all csets public for all csets that were at least n csets before
tip.
Can anyone tell me what that command would look like?
I was thinking a little more about named branches, and realised that
there is no general way to remove the name/label corresponding to a
named branch, other than the special case of obsoleting the branch,
probably via a rebase. (Though only if Evolve is enabled, of course.)
But that only works if the branch has not been merged, say with
default. If it has been merged with default, then this is not an
option, since one cannot obsolete the named branch without also
obsoleting the merged cset, as obsoleting a cset means also obsoleting
its descendants.
In contrast, topic obeys the rewriting semantics of evolve with
--clear.
I suppose one could just never merge, but it seems a bit peculiar to
be trying to use something for temporary use that is designed for
permanent use. I'm not sure what to think about topic, but at least
it's designed for that purpose.
Regards, Faheem Mitha
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@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
_______________________________________________
Evolve-testers mailing list
Evolve-testers@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
_______________________________________________
Evolve-testers mailing list
Evolve-testers@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
