Evolve with named branches vs Evolve with topic branches
Faheem Mitha
faheem at faheem.info
Tue Mar 12 10:54:16 UTC 2019
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 at mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/evolve-testers
> _______________________________________________
> 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