news from the topic experiment

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Sep 22 20:18:50 EDT 2016



On 09/22/2016 11:58 PM, Jun Wu wrote:
> Excerpts from Sean Farley's message of 2016-09-22 14:21:12 -0700:
>>> Having topic in commit metadata makes it hard to rename them, and they are
>>> not fundamentally different from branches imo - i.e. we can probably also
>>> make branches work like the current topics implementation with a some tweaks
>>> - does not seem to need a fresh new concept.
>>
>> I'm not convinced by how hard it is to rename them. That's what
>> evolution is for.
>
> Today I can "vim .hg/bookmarks" and do a massive change to bookmarks. If
> topics is designed to be lightweight and local, it'd better support
> something similar for power users.

It would be easy to have a 'topicedit' command that pops up an editor. 
As no content changes happens, it is easy to rewrite all the changeset 
in memory in a very smooth manners.

> I dislike hash change without actual content change as always. I think most
> people will prefer / expect no hash change with no actual content change.

I much as I would like to avoid it, the current benefit of having it 
(see earlier email) in extra largely out weight the inconvenience. I've 
also found that renaming topic is not something that I end up doing so 
often.

> […]
>> * you can follow the evolution of a topic very easily
>> * it's very familiar with the average user of Mercurial (because of
>>   named branches)
>
> I think our understanding differs on the "it should 'dissolve' upon being
> finished" part (from README). To me, it feels the topic names exist locally
> and they shouldn't be exposed to other peers in changelog. So they are
> guaranteed "dissolved", clean and simple. We can have ".hg/bookmarks" or
> ".hg/remotenames" style state to track them if we do want to exchange
> the information between peers - it will be like remotenames, but one name
> points to a set of changesets, instead of just the head.

We definitely want to be able to exchange them. Evolution allow feature 
branch exchange and topic is giving use the ability to express these 
feature branches. So smooth experience when exchanging is a very 
important part of the design/concept/

> IIUC, the current implementation rewrites changesets to strip the metadata
> when the phase of changesets changes from "non-public" to "public". It
> sounds unnecessary complex to me and brings new problems unnecessarily -
> what if I "hg phase --public -f a-changeset-with-topic" ?

Urg, no. We do -not- "rewrite changeset when the phase of the changeset 
change". We simply stop reading the metadata on public changeset. Phase 
movement stay a simple operation that does not affect the hash.

In the Facebook case, if you want to have an history without (unread) 
topic metadata, you could easily have the pushrebase extension removing 
it when performing its duty.

>> * it works with bundle1
>
> This is some implementation detail that should not affect the design.
> Eventually everyone can upgrade.
>
>>>> One of the nice features of the topic name being in the hash is that a
>>>> server (Bitbucket in this case) can enforce settings with bundle1 since
>>>> we can't really control the client of our users (unlike Facebook and
>>>> Google).
>>>
>>> I don't really understand the feature. Is it some kind of ACL or so?
>>
>> * it allows branch permissions / restrictions
>
> Since it will eventually "dissolve", what's the usecase for permissions on
> topics? For example, if I'm allowed to use topic A but not topic B, I just
> push everything using topic A. The metadata "dissolves" anyway so I don't
> see the difference on the final outcome.
>
>> * only one head per branch
>
> Sounds like remote bookmark is a better fit here.

I'm not sure what you mean here.

(also note that topic+branch allow to tend toward 1 head per 
branch:topic (and could be enforced for bitbucket) while still allowing 
for multiple heads (from pull or intentionally) temporarily which is a 
very useful intermediate state.

Cheers.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list