On 10/13/2016 07:33 AM, Erik van Zijst wrote:
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.

As a foreword, I agree the frontier between named branch and topics is thin. The difference between them are useful but if we can make their management really close, that would be useful. If we did not had the backward compatibility constrains, I would happily have `hg branch foo` create a "topics" and something like `hg branch --long-lived` create what currently is a named branched.

So, thanks for exploring possibilities to make this frontier thiner. However, I can see some issues with some aspects of this proposal, using the same field for either branch or topic make them mostly mutually exclusive. Publishing a topic on a named branch would require to alter the changesets data (and therefore, hash) This means people could use topic only with the default branch (or significant more complexity to work around this). As I understand, Bitbucket enforces a single master branch so that might actually fit your model. This is probably too restricting for the general project (more about that later).

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.

I'm not certain this actually avoid the risk of name collision. People could use the same branch/topic name on different changesets with different values for the flag. That would lead to both a topic and a named branch to exists with the same name.

In all cases we should have the local UI fight hard to prevent people to create collisions between branch and topic. (And some descent way to point out name conflict if they appends).

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.

That is a interesting though.

I think there is some value in having the option to use a (branch, topic) pairs (more about this later), However, the same as people are not really exposed to named branch until they get out of default, a UI could still omit all named branch informations as long as nothing else than "default" exists.

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.

There is some very interesting ramification to this proposal. Even if we do not go with the flag approach. We store the full (branch, topic) pair into the branch field. For example we could use ":" as a separator branch=BRANCH:TOPIC. Not only this would allow old clients to transport the data (we already have that) but this also mean old client can also view and preserve that data (and this is new) even if it does not get the behavior improvement related to topic. That would be a large usability boost for old client.

This is a great lead thank you very much.

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 think having the (named, topics) pair is really useful, especially we can expect great gains from sensible and clear default (merge, rebase, behind computation, etc). In addition, as we can keep hiding the named branch concept for all users who do not needs it. I think we can have a good trade-off regarding extra-feature vs extra-complexity while keeping an initial complexity similar to not having named branch at all. (But as usual, I'm open to be convinced that the right trade-off is somewhere else)

We need to explore a bit more the consequence of having the same topic on multiple branches, but I'm not too worried we can eventually defines some good behavior+constrains pairs that makes this working.

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.

That email was very useful, please send more of them ☺♥


Pierre-Yves David
Mercurial-devel mailing list

Reply via email to