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 _______________________________________________ Mercurial mailing list Mercurial@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial
