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

[Arne Babenhauserheide]

Am Samstag, 26. Januar 2013, 10:26:48 schrieb 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.

Note that master is often not seen as a separate branch by git users (because it always exists) - just like default is often not seen as branch by Mercurial users (because its alias is the empty string: "").

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

Another reason is that tagging actually gives you all the information you need to find the latest stable release. Stable in the model does not only contain releases but actually all code thought to be stable: All code which could be released.

If you want the last released version, you just update via

    hg update -r 'max(branch("stable") and tag())'

In the git model you waste the information that something is on the master branch by also tagging everything on the master branch. 

Since master is only for tagged releases, you state two times that a change is released, while “it is on master” would suffice, as would “it is tagged”. To me that feels like unnecessary bloat.

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

If I understand it right, that makes your default branch what I use as stable branch, except when you have a release branch (then it’s not for the next release but for the release after the next release).

And I think that exception could create quite some confusion, because you have to check if a release branch exists to find out if default is deemed to be the source for the next release.

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

Except for the unclear state of the default branch I agree.

I prefer keeping the branch namespace clean, because that makes the repository structure easier to understand. If you only have default and stable (and maybe a review branch), you can simply look at the branch list and know that every branch except for those 2 (3) is dedicated to developing a feature. So you do not have to mentally parse the branch list to find the features which are currently in development.

Compare those two listings:

# release and hotfix branches

default
feature-x
feature-y
feature-z
hotfix-i
hotfix-j
release-1
release-2
release-3
stable

# just feature branches for big features

default
stable
x
y
z

Arguably the first listing is easier for maintainers: They see hotfixes and releases which are currently in the works (instead of looking at `hg log -r 'branch("stable")'` or `hg log -b stable`). 

But though the maintainers are often the ones who pick the workflow, they are a small minority of the people who work with the code, and they are the ones who need the least help, because they already work with the structure everyday, while the developers mostly work on their features without necessarily having an overview of all the stuff happening right now). The cost for the maintainers only hits a few people but the cost to the regular developers hits all people.

So I think that the workflow should cater to the majority of the people who work with the code, not to the minority which knows it best.

I think the maintainer-centric models which I feel are favored in the git-world arose from the very hierarchic structure of the Linux-Kernel (one person and a few helpers managing 1000 developers) and from hobby-projects where the maintainer works a few hours a week, so the time he can invest is quickly saturated (especially when using a tool like git, which can have quite high overhead whenever problems crop up… at least from my experience).

Best wishes,
Arne
--
Konstruktive Kritik: 

- http://draketo.de/licht/krude-ideen/konstruktive-kritik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130126/e7f48c95/attachment.asc>