> 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 [EMAIL PROTECTED] -- Florian Ebeling [EMAIL PROTECTED] _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev