news from the topic experiment

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Sep 27 08:19:06 EDT 2016



On 09/24/2016 03:21 AM, Long Vu wrote:
>
> On Sep 23, 2016 17:21, "Pierre-Yves David"
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
> wrote:
>>
>>
>>
>> On 09/23/2016 06:08 PM, Long Vu wrote:
>>>
>>> On Fri, Sep 23, 2016 at 11:50 AM, Long Vu <long.vu at intelerad.com
> <mailto:long.vu at intelerad.com>> wrote:
>>>>
>>>>
>>>> I emulate git lightweight branching by basically using named branch
>>>> with evolve and working on the fork of the "master" repo.
>>>>
>>>
>>> We only enable evolve and non-publishing on the fork repo to make sure
>>> we can not alter history on the master repo where the releases are
>>> coming from.
>>
>>
>> You could enable evolution on the main (publishing) repository. It
> will allow people pushing changeset on the non-publishing one to get
> proper obs-markers when they directly pull from the publishing one.
>
> What do you mean by getting proper obs-markers?
>
> I forgot a step.  The final "release" is a push to master, followed by a
> push to the fork to propagate the public phase to the fork.  Is phase
> propagation what you meant?

I mean obsolescence marker propagation. Do you have enabled on either of 
your central repository ?

>>> We have one bug/feature per branch on the fork repo so it's very easy
>>> to manage when we have many concurrent bugs/projects to juggle.
>>
>>
>> From your explanation in the previous email. It sounds like you are
> using named-branch in a way close to what topic would provide you. Maybe
> you should try topic for a bit and tell use how it feels.
>
> Pardon my ignorance because I have not yet tried topic, but since evolve
> + named branch already gave me what topic would provide, what makes
> topic superior?
>
> Why would I want to try it other than because I am curious?
>
> Not saying it's not useful.  Just want to know what it brings to the table.

As topic is designed for feature branch you would get various small 
advantage that will smooth your experience out:

- Simpler push: pushing new topic to your non-publishing repo do not 
requires --force (if the non-publishing repository have topic enabled). 
Pushing to your main repository also make the topic disappear without 
the need of an initial rebase.

- Simpler and less error prone rebase: Running `hg rebase` from your 
topic will automatically update it on the head of the 'default' branch. 
Without removing the topic information.

- Better command to work with your stack

   + `hg topic` list you active feature branch. `hg topic --verbose` 
list various statistic`

   + `hg stack` show your current stack an help you to move within it,

   + `hg evolve --all` will always evolve all of your topic only.

   + `hg next` and `hg prev` stick to your current topic.

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list