Merging to the release_1_6 branch (was: Re: Fwd: http://trac.macports.org/ticket/15109)

[Caspar Florian Ebeling]

> This is why I think that releases should be tags on trunk, with a
> convergence period before each release.  This project is not big
> enough and does not have the manpower or written guidelines and a
> release engineer driving the process on a daily basis which are
> necessary to really do a two-branch model.  That is merely my opinion,
> of course, but it's driven by some experience in this area.

This is exactly what I have been preaching, but I think it changes
with Git. I know that saying this might well be boring by now, but Git
eases the whole branch handling a lot. And svnmerge.py is really
not a substitute here. I used it for a feature branch of a project and
some file renamings made things go haywire. It was certainly not
the reassurement your actually want to get out of version control.

But git mostly makes branches a private thing, so that effectively
their number rather gets reduced, or at least the number of public
ones gets reduced. The existing branches tend to be feature-specific,
and mainline
stays sane because branches only get merged in once they are
not questionable anymore.

Florian


--
Florian Ebeling
florian.ebeling at gmail.com



-- 
Florian Ebeling
florian.ebeling at gmail.com