On 09/24/2016 03:21 AM, Long Vu wrote:
On Sep 23, 2016 17:21, "Pierre-Yves David"
<pierre-yves.da...@ens-lyon.org <mailto:pierre-yves.da...@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...@intelerad.com
<mailto:long...@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
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
