Hi Johannes, 2009/8/29 Johannes Schlüter <johan...@php.net>:
[snip] > I'm not toooo used to subversion therefore I'd like some comments about > this procedure: > > 1) Monday evening branch of a release branch owned by me > $ svn cp branches/PHP_5_3 branches/php_5_3_1 > Question A: using php as in our tags or PHP as in our branches? I would suggest keeping "PHP" for a branch because it will be used as is, it can be renamed with "php" while doing the svn copy|move to tags. More details after. > Question B: can svn merge be used to get changes from PHP_5_3 or is a > manual merge better? The merge tracking is an interesting option, I would greatly recommend using it. You can easily use the "-c" option to merge a specific revision number. > 2) Tuesday: Change the version > $ vi branches/php_5_3_1/main/php_version.h etc. > 3) making the branch a tag > $ svn mv branches/php_5_3_1 tags/php_5_3_1 I would suggest a copy rather than a move because you may have to create different tags (RC1, RC2,...) from this branch. $ svn copy branches/PHP_5_3_1 tags/php_5_3_1RC1 > 4) merge the tag into the PHP_5_3 branch > $ cd branches/PHP_5_3 && svn merge ../tags/php_5_3_1 > The idea would be that the release appears in the > branch's history and nothing is being lost There is no such merge needed, svn keeps track of copies and merges. >From svn clients, it is perfectly possible to generate a graph with copies (tags) made from that branch. > Question: Does that make any sense? IMHO, No. > 5) Change the version to RC2-dev > $ vi branches/PHP_5_3/main/php_version.h etc. This should be made in branches/PHP_5_3_1, before the tag is created. > Feedback on this procedure and svn usage welcome. If this doesn't work > out the procedure can be changed for the next release and I guess a RC > is a better test than a "proper" release. > > johannes To summarize, I would recommend the following steps: 0° Creating the 5.3.1 branch $ svn cp branches/PHP_5_3 branches/PHP_5_3_1 $ vi branches/PHP_5_3_1/main/php_version.h etc. // Filling next tag information, e.g. 5.3.1RC1 $ svn ci 1° Creating the 5.3.1RC(\d) tag $ svn copy branches/PHP_5_3_1 tags/php_5_3_1RC1 2° Lifetime of PHP_5_3_1: a) Patching PHP_5_3_1 $ svn merge -c xxxxx branches/PHP_5_3 branches/PHP_5_3_1 b) Fixing next version info $ vi branches/PHP_5_3_1/main/php_version.h etc. // Filling next tag information, e.g. 5.3.1RC2, 5.3.1... 3° Goto 1° unless tagging the final release 4° Tagging final release: $ svn copy branches/PHP_5_3_1 tags/php_5_3_1 (optionally, branches/PHP_5_3_1 could be removed, but shouldn't be "moved" as it would make a weird graph for merges/copies tracking) Notes: Developers commit should be made to branches/PHP_5_3 *only* Release manager(s) only commit "svn merge" operations to branches/PHP_5_3_1 Tags are strictly read-only copies created with "php" Branches are always created using "PHP" Does this sounds good for you? -- Patrick Allaert --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
