A complete Mercurial branching strategy (writeup)
82 views
Skip to first unread message
Arne Babenhauserheide
Aug 14, 2012, 9:15:51 PM8/14/12
to Mercurial Users
Hi,
I just described a complete branching strategy to mimick a git
strategy used is freenet¹, and I and thought you might be interested:
http://draketo.de/light/english/mercurial/complete-branching-strategy
(or http://draketo.de/node/513 )
¹: Well, the git strategy should be used in Freenet, but in reality it
gets muddled up all the time… I think this Mercurial flavor of the
branching strategy will be much easier.
Best wishes,
Arne
_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial
Angel Ezquerra
Aug 15, 2012, 4:27:14 AM8/15/12
to arne...@web.de, Mercurial Users
On Wed, Aug 15, 2012 at 3:15 AM, Arne Babenhauserheide <arne...@web.de> wrote:
> Hi,
>
> I just described a complete branching strategy to mimick a git
> strategy used is freenet¹, and I and thought you might be interested:
>
> http://draketo.de/light/english/mercurial/complete-branching-strategy
> (or http://draketo.de/node/513 )
>
> ¹: Well, the git strategy should be used in Freenet, but in reality it
> gets muddled up all the time… I think this Mercurial flavor of the
> branching strategy will be much easier.
>
> Best wishes,
> Arne
Arne,
> Hi,
>
> I just described a complete branching strategy to mimick a git
> strategy used is freenet¹, and I and thought you might be interested:
>
> http://draketo.de/light/english/mercurial/complete-branching-strategy
> (or http://draketo.de/node/513 )
>
> ¹: Well, the git strategy should be used in Freenet, but in reality it
> gets muddled up all the time… I think this Mercurial flavor of the
> branching strategy will be much easier.
>
> Best wishes,
> Arne
I went through your document, and one thing I missed, is an
explanation of why you need to merge hotfixes into the tip of stable.
Your explanation gives the impression that you only need that
if/because you want to get those hotfixes on the latest release as
well. In fact you need to merge because you cannot push a branch that
has multiple heads. This is another reason for creating "branch
releases" when you need to do a hot fix.
Cheers,
Angel
Todd Greer
Aug 15, 2012, 3:46:31 PM8/15/12
to arne...@web.de, Mercurial Users
Arne Babenhauserheide wrote:
>I just described a complete branching strategy to mimick a git strategy used is freenet¹, and I and thought you might be interested:
>
>http://draketo.de/light/english/mercurial/complete-branching-strategy
>(or http://draketo.de/node/513 )
Looks like a nice write-up. I noticed that you don't discuss closing feature branches. That would be a good addition.
>I just described a complete branching strategy to mimick a git strategy used is freenet¹, and I and thought you might be interested:
>
>http://draketo.de/light/english/mercurial/complete-branching-strategy
>(or http://draketo.de/node/513 )
--
Todd Greer, Director of Development, Affinegy, Inc.
1705 S. Capital of Texas Hwy, Ste. 310, Austin, TX, 78746
O 512.535.1700 | F 512.233.2477
tgr...@affinegy.com http://affinegy.com
Martin Geisler
Aug 16, 2012, 3:43:18 AM8/16/12
to Todd Greer, Mercurial Users
Todd Greer <TGr...@affinegy.com> writes:
> Arne Babenhauserheide wrote:
>
>>I just described a complete branching strategy to mimick a git strategy used is freenet¹, and I and thought you might be interested:
>>
>>http://draketo.de/light/english/mercurial/complete-branching-strategy
>>(or http://draketo.de/node/513 )
>
> Looks like a nice write-up. I noticed that you don't discuss closing
> feature branches. That would be a good addition.
I wrote a bit about closing named branches here:
> Arne Babenhauserheide wrote:
>
>>I just described a complete branching strategy to mimick a git strategy used is freenet¹, and I and thought you might be interested:
>>
>>http://draketo.de/light/english/mercurial/complete-branching-strategy
>>(or http://draketo.de/node/513 )
>
> Looks like a nice write-up. I noticed that you don't discuss closing
> feature branches. That would be a good addition.
http://mercurial.aragost.com/kick-start/en/tasks/
--
Martin Geisler
aragost Trifork
Commercial Mercurial support
http://aragost.com/mercurial/
Arne Babenhauserheide
Aug 18, 2012, 4:38:00 AM8/18/12
to Angel Ezquerra, Mercurial Users
Hi Angel,
Am Mittwoch, 15. August 2012, 10:27:14 schrieb Angel Ezquerra:
> I went through your document, and one thing I missed, is an
> explanation of why you need to merge hotfixes into the tip of stable.
Hm, yes… thanks for catching that.
> Your explanation gives the impression that you only need that
> if/because you want to get those hotfixes on the latest release as
> well. In fact you need to merge because you cannot push a branch that
> has multiple heads.
Well, you can push it, but it’s impolite. (I assume you mean the footnote for
very distinct releases)
There is a deeper reason for the merge, though: It records the decision what
to do with applied changes in future.
To define this, you merge old releases to each release, into stable and into
default.
I now added the following to the strategy:
Merging the releases into each other in order ensures that
the relationship of the their changes to later changes is
clear, recorded and will be applied automatically by
Mercurial in future merges6. Additionally it is considered
impolite to other developers to keep multiple heads in one
branch, because with multiple heads other developers do not
know the canonical tip of the branch which they should use to
make their changes - or in case of stable, which head they
should merge to for preparing the next release. This model
requires one merge per maintained release to create a bugfix
version of an old release. By adding release branches, you
remove that overhead by stating clearly, that changes to old
versions should never affect new versions, except if those
changes are explicitely merged into the new versions.
> This is another reason for creating "branch
> releases" when you need to do a hot fix.
The reason I see for using branch releases is, that you then state explicitely
that the changes in the releases are independent.
Best wishes,
Arne
--
A man in the streets faces a knife.
Two policemen are there it once. They raise a sign:
“Illegal Scene! Noone may watch this!”
The man gets robbed and stabbed and bleeds to death.
The police had to hold the sign.
…Welcome to Europe, citizen. Censorship is beautiful.
( http://draketo.de/stichwort/censorship )
Am Mittwoch, 15. August 2012, 10:27:14 schrieb Angel Ezquerra:
> I went through your document, and one thing I missed, is an
> explanation of why you need to merge hotfixes into the tip of stable.
> Your explanation gives the impression that you only need that
> if/because you want to get those hotfixes on the latest release as
> well. In fact you need to merge because you cannot push a branch that
> has multiple heads.
very distinct releases)
There is a deeper reason for the merge, though: It records the decision what
to do with applied changes in future.
To define this, you merge old releases to each release, into stable and into
default.
I now added the following to the strategy:
Merging the releases into each other in order ensures that
the relationship of the their changes to later changes is
clear, recorded and will be applied automatically by
Mercurial in future merges6. Additionally it is considered
impolite to other developers to keep multiple heads in one
branch, because with multiple heads other developers do not
know the canonical tip of the branch which they should use to
make their changes - or in case of stable, which head they
should merge to for preparing the next release. This model
requires one merge per maintained release to create a bugfix
version of an old release. By adding release branches, you
remove that overhead by stating clearly, that changes to old
versions should never affect new versions, except if those
changes are explicitely merged into the new versions.
> This is another reason for creating "branch
> releases" when you need to do a hot fix.
that the changes in the releases are independent.
Best wishes,
Arne
--
A man in the streets faces a knife.
Two policemen are there it once. They raise a sign:
“Illegal Scene! Noone may watch this!”
The man gets robbed and stabbed and bleeds to death.
The police had to hold the sign.
…Welcome to Europe, citizen. Censorship is beautiful.
( http://draketo.de/stichwort/censorship )
Arne Babenhauserheide
Aug 18, 2012, 5:35:44 AM8/18/12
to Todd Greer, Mercurial Users
Hi Todd,
Am Mittwoch, 15. August 2012, 19:46:31 schrieb Todd Greer:
> Arne Babenhauserheide wrote:
> > http://draketo.de/light/english/mercurial/complete-branching-strategy
> Looks like a nice write-up. I noticed that you don't discuss closing feature
> branches. That would be a good addition.
Good catch - thanks!
I now added closing branches as an item to feature branches.
http://draketo.de/node/513#feature-branches
This makes feature branches a bit more complex, but I think it helps a lot in
actual development, because the current state of the repository stays cleaner.
### Feature branches
*Now we want to do some larger development, so we use a feature branch. The
one commit could be an arbitrary number of commits, and as long as you stay in
your branch, the development of your collegues will not disturb your own work.
Once the feature is finished, we merge it into default. That gives us
changesets 9 to 11. Changeset 10 is a commit added in-between on the default
branch.*
o changeset: 16:2088b93fb3f4
|\ parent: 14:684c6176ce71
| | parent: 15:168429fdaf57
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:48 2012 +0200
| | summary: merged finished feature x into default
| |
| o changeset: 15:168429fdaf57
| | branch: feature-x
| | parent: 13:e3985e582fc4
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:47 2012 +0200
| | summary: finished feature x
| |
o | changeset: 14:684c6176ce71
|\| parent: 12:70d38749f7dd
| | parent: 13:e3985e582fc4
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:46 2012 +0200
| | summary: merged feature x into default
| |
| o changeset: 13:e3985e582fc4
|/ branch: feature-x
| user: Arne Babenhauserheide <b...@draketo.de>
| date: Sat Aug 18 10:53:45 2012 +0200
| summary: x
|
o changeset: 12:70d38749f7dd
|\ parent: 9:760af400d190
| | parent: 11:cf4cf65df405
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:45 2012 +0200
| | summary: merged stable into default: ready for more development
Commands:
* Start the feature
hg branch feature-x
(edit)
hg ci -m "message"
* Do an intermediate commit on default
hg update default
(edit)
hg ci -m "message"
* Continue working on the feature
hg update feature-x
(edit)
hg ci -m "message"
* Merge the feature
hg update default
hg merge feature-x
hg ci -m "merged feature x into default"`
* Close and merge a finished feature
hg update feature-x
hg ci --close-branch -m "finished feature x"
hg update default; hg merge feature-x
hg ci -m "merged finished feature x into default"
*Note: Closing the feature branch hides that branch in the output of `hg
heads` and `hg branches` (except when using `--closed`) to make the repository
state lean and simple while still keeping the feature branch information in
history. It shows your collegues, that they no longer have to keep the feature
in mind as soon as they merge the most recent changes from the default branch
into their own feature branches.*
*Note: To make the final merge of your feature into default easier, you can
regularly merge the default branch into the feature branch.*
Best wishes,
Arne
--
Konstruktive Kritik:
- http://draketo.de/licht/krude-ideen/konstruktive-kritik
Am Mittwoch, 15. August 2012, 19:46:31 schrieb Todd Greer:
> Arne Babenhauserheide wrote:
> > http://draketo.de/light/english/mercurial/complete-branching-strategy
> Looks like a nice write-up. I noticed that you don't discuss closing feature
> branches. That would be a good addition.
I now added closing branches as an item to feature branches.
http://draketo.de/node/513#feature-branches
This makes feature branches a bit more complex, but I think it helps a lot in
actual development, because the current state of the repository stays cleaner.
### Feature branches
*Now we want to do some larger development, so we use a feature branch. The
one commit could be an arbitrary number of commits, and as long as you stay in
your branch, the development of your collegues will not disturb your own work.
Once the feature is finished, we merge it into default. That gives us
changesets 9 to 11. Changeset 10 is a commit added in-between on the default
branch.*
o changeset: 16:2088b93fb3f4
|\ parent: 14:684c6176ce71
| | parent: 15:168429fdaf57
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:48 2012 +0200
| | summary: merged finished feature x into default
| |
| o changeset: 15:168429fdaf57
| | branch: feature-x
| | parent: 13:e3985e582fc4
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:47 2012 +0200
| | summary: finished feature x
| |
o | changeset: 14:684c6176ce71
|\| parent: 12:70d38749f7dd
| | parent: 13:e3985e582fc4
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:46 2012 +0200
| | summary: merged feature x into default
| |
| o changeset: 13:e3985e582fc4
|/ branch: feature-x
| user: Arne Babenhauserheide <b...@draketo.de>
| date: Sat Aug 18 10:53:45 2012 +0200
| summary: x
|
o changeset: 12:70d38749f7dd
|\ parent: 9:760af400d190
| | parent: 11:cf4cf65df405
| | user: Arne Babenhauserheide <b...@draketo.de>
| | date: Sat Aug 18 10:53:45 2012 +0200
| | summary: merged stable into default: ready for more development
Commands:
* Start the feature
hg branch feature-x
(edit)
hg ci -m "message"
* Do an intermediate commit on default
hg update default
(edit)
hg ci -m "message"
* Continue working on the feature
hg update feature-x
(edit)
hg ci -m "message"
* Merge the feature
hg update default
hg merge feature-x
hg ci -m "merged feature x into default"`
* Close and merge a finished feature
hg update feature-x
hg ci --close-branch -m "finished feature x"
hg update default; hg merge feature-x
hg ci -m "merged finished feature x into default"
*Note: Closing the feature branch hides that branch in the output of `hg
heads` and `hg branches` (except when using `--closed`) to make the repository
state lean and simple while still keeping the feature branch information in
history. It shows your collegues, that they no longer have to keep the feature
in mind as soon as they merge the most recent changes from the default branch
into their own feature branches.*
*Note: To make the final merge of your feature into default easier, you can
regularly merge the default branch into the feature branch.*
Best wishes,
Arne
--
Konstruktive Kritik:
- http://draketo.de/licht/krude-ideen/konstruktive-kritik
Arne Babenhauserheide
Aug 18, 2012, 5:51:47 AM8/18/12
to Martin Geisler, Mercurial Users
Am Donnerstag, 16. August 2012, 09:43:18 schrieb Martin Geisler:
> I wrote a bit about closing named branches here:
>
> http://mercurial.aragost.com/kick-start/en/tasks/
If my writeup would be useful for kick-start, feel free to use it, since IIRC
> I wrote a bit about closing named branches here:
>
> http://mercurial.aragost.com/kick-start/en/tasks/
kick-start is GPL, too.
Best wishes,
Arne
--
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.
→ http://1w6.org
Dave S
Aug 19, 2012, 5:22:56 AM8/19/12
to mercurial
Arne Babenhauserheide (arne_bab at web.de), on Sat Aug 18 04:35:44 CDT 2012
added this description:
> ### Feature branches
>
> *Now we want to do some larger development, so we use a feature branch. The
> one commit could be an arbitrary number of commits, and as long as you stay in
perhaps "The one commit shown here ..." would be clearer
> your branch, the development of your collegues will not disturb your own work.
colleagues
> Once the feature is finished, we merge it into default. That gives us
> changesets 9 to 11. Changeset 10 is a commit added in-between on the default
> branch.*
A nicely done writeup; thank you.
/dps
--
test signature -- please apply at front gate on Tuesdays only.
added this description:
> ### Feature branches
>
> *Now we want to do some larger development, so we use a feature branch. The
> one commit could be an arbitrary number of commits, and as long as you stay in
> your branch, the development of your collegues will not disturb your own work.
> Once the feature is finished, we merge it into default. That gives us
> changesets 9 to 11. Changeset 10 is a commit added in-between on the default
> branch.*
/dps
--
test signature -- please apply at front gate on Tuesdays only.
Arne Babenhauserheide
Sep 4, 2012, 6:09:49 PM9/4/12
to merc...@selenic.com, Dave S
Am Sonntag, 19. August 2012, 02:22:56 schrieb Dave S:
>> http://draketo.de/light/english/mercurial/complete-branching-strategy
> A nicely done writeup; thank you.
I’m glad you like it :)
Best wishes,
Arne
PS: Since it’s GPLv3+ like almost everything on that page, feel free to use it
:)
>> http://draketo.de/light/english/mercurial/complete-branching-strategy
> perhaps "The one commit shown here ..." would be clearer
Included, thanks!
> A nicely done writeup; thank you.
Best wishes,
Arne
PS: Since it’s GPLv3+ like almost everything on that page, feel free to use it
:)
Arne Babenhauserheide
Sep 4, 2012, 6:21:44 PM9/4/12
to Mercurial Users
Hi,
I now added graphs and extensions to the branching strategy.
http://draketo.de/light/english/mercurial/complete-branching-strategy
(or http://draketo.de/node/513 )
The graphs visualize the workflow for 3 groups: developers, maintainers and
users.
The extensions cover multiple releases maintained side-by-side¹, release-tasks
which have to be done before a real release² and third-party verification³
(the latter two as footnotes).
¹: http://draketo.de/node/513#multiple-releases
²: http://draketo.de/node/513#fn:release-preparation
³: http://draketo.de/node/513#fn:verification
Graphs are created from ascii-source using ditaa and emacs org-mode:
- graph: http://draketo.de/files/hgbranchingoverview_2.png
- source: http://draketo.de/files/2012-09-03-Mo-hg-branching-diagrams_6.org
- ditaa: http://ditaa.sf.net
- orgmode: http://orgmode.org
Best wishes,
Arne
Am Mittwoch, 15. August 2012, 03:15:51 schrieb Arne Babenhauserheide:
> Hi,
>
> I just described a complete branching strategy to mimick a git
> strategy used is freenet¹, and I and thought you might be interested:
>
> http://draketo.de/light/english/mercurial/complete-branching-strategy
> (or http://draketo.de/node/513 )
>
> ¹: Well, the git strategy should be used in Freenet, but in reality it
> gets muddled up all the time… I think this Mercurial flavor of the
> branching strategy will be much easier.
>
> Best wishes,
> Arne
--
Ich hab' nichts zu verbergen – hab ich gedacht:
- http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen
I now added graphs and extensions to the branching strategy.
http://draketo.de/light/english/mercurial/complete-branching-strategy
(or http://draketo.de/node/513 )
users.
The extensions cover multiple releases maintained side-by-side¹, release-tasks
which have to be done before a real release² and third-party verification³
(the latter two as footnotes).
¹: http://draketo.de/node/513#multiple-releases
²: http://draketo.de/node/513#fn:release-preparation
³: http://draketo.de/node/513#fn:verification
Graphs are created from ascii-source using ditaa and emacs org-mode:
- graph: http://draketo.de/files/hgbranchingoverview_2.png
- source: http://draketo.de/files/2012-09-03-Mo-hg-branching-diagrams_6.org
- ditaa: http://ditaa.sf.net
- orgmode: http://orgmode.org
Best wishes,
Arne
Am Mittwoch, 15. August 2012, 03:15:51 schrieb Arne Babenhauserheide:
> Hi,
>
> I just described a complete branching strategy to mimick a git
> strategy used is freenet¹, and I and thought you might be interested:
>
> http://draketo.de/light/english/mercurial/complete-branching-strategy
> (or http://draketo.de/node/513 )
>
> ¹: Well, the git strategy should be used in Freenet, but in reality it
> gets muddled up all the time… I think this Mercurial flavor of the
> branching strategy will be much easier.
>
> Best wishes,
> Arne
Ich hab' nichts zu verbergen – hab ich gedacht:
- http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen
Reply all
Reply to author
Forward
0 new messages