transforming the 5-branch-types !git model to the 2-branch !hg model with the same functionality
ike
icasteleyn at hotmail.com
Fri Jan 25 22:43:36 UTC 2013
Hi,
I'm moving from subversion to mercurial with my company and would also use
the branch-model by nvie.
So I'm not an expert on mercurial or git, but did research on both systems
and on the branch-model.
I want to respond to better understand the branching-model you describe
since it could make my life easier in future.
> * Tags are simple in-history objets, so we need no special branch for
> them: a tag signifies a release (down to 4 branch-types - and no more
> duplication of information, since in the git-model a release is shown by a
> tag *and* a merge to master).
This is unclear to me.
I don't actually see a 5th-branch.
Git-model: dev is branched to release (tested) and then merged to stable and
dev + tag. The release branch can be skipped (you describe this in your post
as "explicit review branch" or even "release preparation phase")
Your-model: dev is merged to stable + tag.
A merge is necessary to get changes across
> * Hotfixes are simple commits on stable, so we also need no branch for
> them (down to 3 branch-types)
I can agree with this, but not all hotfixes are trivial.
It's a hotfix because it needs to start from the stable-branch, but the
amount of work that the hotfix implies would drive the decision if a
hotfix-branch must be created or just be commits on stable.
> * And if we only maintain one release at a time, we only need one branch
> for them: stable (down from branch-type to single branch)
I don't understand what you mean here.
> * And feature branches are not required for clean separation since
> mercurial can easily cope with multiple heads in a branch, so developers
> only have to worry about them if they want to use them (down to 2
> mandatory branches).
Clear and is a matter of preference I guess.
> * And since the default branch is the branch to which you update
> automatically when you clone a repository, *new developers don’t have to
> worry about branches at all*.
Also clear
Perhaps it's because I have a model in my mind that would work for my
company.
feature-branches: all work happens on feature branches started from default
default-branch: receives all finished features, applied hotfixes and
represents what goes into the next stable version
release-branch: this would be created when you want to create the next
stable version. Branch of default and then do testing (fixing found bugs) on
the release-branch. This also leaves the default-branch available to receive
new finished features (that would be for version next2)
stable-branch: the version that is currently beeing used by users
hotfix-branch: need to deliver some changes to your users with only their
current version and the new changes (since what's on default might not be
ready yet)
Best regards,
Ike
--
View this message in context: http://mercurial.808500.n3.nabble.com/transforming-the-5-branch-types-git-model-to-the-2-branch-hg-model-with-the-same-functionality-tp3997443p3997639.html
Sent from the General mailing list archive at Nabble.com.
More information about the Mercurial
mailing list