Working on our Bitbucket spike I wondered if topics could perhaps
benefit from a small simplification. Instead of adding the topic name
as an additional field, what if we defined a topic commit by merely
adding a boolean property to the meta dict; e.g. `is_topic: True`?
Named branches would not have the property set.

It would seem to me that this could have some benefits:

1. There would be no risk of a name collision between the branch and
topic namespaces.

During our little Bitbucket spike and demo during the sprint we made
the assumption that topics and branches should never clash, which
allowed me to put them in the existing, single branches namespace.
This would seem desirable as topics are essentially branches, with the
only real difference being their anticipated longevity. This greatly
simplified the UI as hardly anything needed to be modified.

2. Interoperability with non-topic clients would mostly just work.

Currently, when cloning a topics repo with an old client, all topics
would appear as an amorphous mess of anonymous heads on default.
Instead, if we dropped the separate topic name field and just used the
branch name as the topic name, an old client would see the same layout
as a topic-enabled client and while an old client would not be able to
create new topic commits, read-only clients should be totally fine.
This could be a big boon for existing ecosystem tools like CI servers
that wouldn't have to be modified.

The only downside I can think of is that when the topic and original
branch name are separate fields, that a topic sort of remains
associated with the branch it was based on. This would provide
implicit merge and rebase targets and therefore slightly shorter
commands. However, I'm not sure that's worth giving up the above

I do realize it's quite possible I'm overlooking other reasons for
having topics encoded as an additional namespace, separate from the
named branch name.


On Tue, Oct 11, 2016 at 11:29 AM, Gregory Szorc <> wrote:
>> On Oct 10, 2016, at 10:51, Denis Laxalde <> wrote:
>> Gregory Szorc a écrit :
>>> There are still some areas for improving topics.
>>> 1) `hg log` still shows *all* changesets in the repository. This is
>>> confusing for users that don't want to be burdened with the complexity
>>> of multiple heads. I'd like the behavior of `hg log` to only show
>>> ancestors - and possibly descendants - of the working directory
>>> changeset when the working directory changeset is unpublished and has a
>>> topic. If we show descendants, we should delimit the current changeset
>>> somehow, possibly by making -G or a mode like it the default in this
>>> scenario. Realistically, I think `hg log` should behave like `hg log -f`
>>> and `hg log --children` should supplement that with descendants and a
>>> marking of the wdir changeset. If there is a branch point in the
>>> descendants, we should automatically add the graphical view because
>>> showing changesets from multiple DAG heads without the graphical view is
>>> really confusing. I can also make the argument that the graphical view
>>> should always be shown so merge commits can be rendered properly.
>> It seems to me that, if we consider topics as lightweight *branches*, we
>> can improve (part of) this :
>> * when on a topic, `hg log` could only show changesets in the current
>> topic (and their public ancestors);
>> * when not on a topic, a bare `hg log` could only show changesets
>> without a topic;
>> * with an additional -t/--topic option to log command, we could see
>> changesets of a particular topic even we not activated.
> Per discussion on Sunday, we decided to introduce "hg display <view>" as a 
> new mechanism that essentially is a named (revset, template) pair to show 
> useful views of repository data (not necessarily limited to changeset data).
> We'll prefer to use "hg display" for common queries instead of adding yet 
> more functionality and special behavior to "hg log."
> I'll hopefully send out an RFC series soon that explains "hg display" in more 
> detail.
>> Basically, just like with named branches, I think.
>> If we follow the same idea (topics are branches), why not considering
>> make `hg pull` behave differently with topics?
>> I would imagine that `hg pull` will not fetch any changeset with a
>> topic unless the client is on a topic that got updated remotely. But,
>> the server response could list information about available topics,
>> something like:
>>   remote: new topics "bugfix1", "newfeature22"
>>   remote: new changes in topics "foo"
>>   remote: topics "importbugfix", "docstringtypo" got published
>> And add a -t/--topic option to `hg pull` to explicitly pull some topic(s).
>> Here, this diverges from `hg pull` behavior with respect to named
>> branches (all branches are pulled by default). But this might be an
>> occasion to "fix" things?
>> --
>> Denis Laxalde
>> Logilab
> _______________________________________________
> Mercurial-devel mailing list
Mercurial-devel mailing list

Reply via email to