transforming the 5-branch-types !git model to the 2-branch !hg model with the same functionality

[Harvey Chapman]

On Jan 25, 2013, at 5:43 PM, ike <icasteleyn at hotmail.com> wrote:
>> * 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.

The 5th branch is master in the git model. Nvie uses master for tags only.


Before I comment further, an issue with Arne's model shows up in your next two questions. The issue is that Arne's model, unlike the git model, does not guarantee that stable will _always_ be stable whenever checked out. Arne's design uses stable to apply hot fixes and to finish releases. The git model only puts something into master when it's done and tagged. That's the real reason why Arne's model lacks the release and hotfix branches, to keep the diagram simpler. However, there's nothing stopping you from using explicit named branches for releases and hotfixes to make sure they are never checked out by accident. An alternative, though, is to have multiple repos. Have one pristine, publicly accessible repo that is only pushed to after tagging. Then have your central development repo feed into that one. The development repo can use Arne's simpler model since developers should be wise enough to know how to navigate the stable branch.

>> * 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.

Since mercurial has true, anonymous branching, you just update to your release tag, make your hotfix in one or more commits, tag it, and then merge stable back into default (assuming only one maintained release at a time, the most recent). However, there's nothing stopping you from giving your hotfix a branch name. Even better, why not use a bookmark for the best of both worlds: clearly labeled, but temporary. Even if we have more than one hotfix in development, with mercurial you can use anonymous branches (with optional bookmarks) where as git needs a branch (which is really a bookmark because git doesn't have named branches).

>> * 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.

With mercurial, we only need one branch, stable, if we only ever have one active release. Again, it's whether you need to guarantee that stable is always "stable."

> 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)

Looks good. Your model is just a regimented version of Arne's and is closer to the git model. If you got rid of the required branch names in your model, it looks just like Arne's.