Hi,
I thought I sent the warning out on thursday but can't find it in my
internals folder therefore the notice:
We certainly should get 5.3.1 rolling and therefore I'm planning RC1
on Tuesday evening European time
I'm not toooo used to subversion therefore I'd like some comments about
this procedure:
- 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?
Question B: can svn merge be used to get changes from PHP_5_3 or is a
manual merge better? - Tuesday: Change the version
$ vi branches/php_5_3_1/main/php_version.h etc. - making the branch a tag
$ svn mv branches/php_5_3_1 tags/php_5_3_1 - 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
Question: Does that make any sense? - Change the version to RC2-dev
$ vi branches/PHP_5_3/main/php_version.h etc.
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
Hi,
I thought I sent the warning out on thursday but can't find it in my
internals folder therefore the notice:We certainly should get 5.3.1 rolling and therefore I'm planning RC1
on Tuesday evening European timeI'm not toooo used to subversion therefore I'd like some comments about
this procedure:
- 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?
Question B: can svn merge be used to get changes from PHP_5_3 or is a
manual merge better?- Tuesday: Change the version
$ vi branches/php_5_3_1/main/php_version.h etc.- making the branch a tag
$ svn mv branches/php_5_3_1 tags/php_5_3_1- 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
Question: Does that make any sense?- Change the version to RC2-dev
$ vi branches/PHP_5_3/main/php_version.h etc.
I don't understand why you are merging things back and forth like that.
Just keep it simple:
PHP_5_3 is open for any commits, php_5_3_1 is only for commits you pick
into it. And only do manual merge. Otherwise you won't be merging what
you want for real. ;)
Don't mess with version in PHP_5_3, only in php_5_3_1 where you create
the RCs from. And please, no more tags, those are totally useless in SVN
world, IMO.
--Jani
Hi,
I don't understand why you are merging things back and forth like that.
Just keep it simple:PHP_5_3 is open for any commits, php_5_3_1 is only for commits you pick
into it. And only do manual merge. Otherwise you won't be merging what
you want for real. ;)Don't mess with version in PHP_5_3, only in php_5_3_1 where you create
the RCs from. And please, no more tags, those are totally useless in SVN
world, IMO.
A "tag" makes sense to see what exactly was released and for that it
makes (in my opinion) sense if the svn mv/cp of the directory is the
last operation since that one can easily be identified. If we have no
separation between a branch and a tag this might be more problematic.
But I asked this on purpose, seeking advice, and don't have too strong
opinions there.
johannes
Hi Johannes,
2009/8/29 Johannes Schlüter johannes@php.net:
[snip]
I'm not toooo used to subversion therefore I'd like some comments about
this procedure:
- 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.
- Tuesday: Change the version
$ vi branches/php_5_3_1/main/php_version.h etc.- 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
- 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.
- 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
Hi,
thanks for your suggestions, some comments below:
- Tuesday: Change the version
$ vi branches/php_5_3_1/main/php_version.h etc.- making the branch a tag
$ svn mv branches/php_5_3_1 tags/php_5_3_1I would suggest a copy rather than a move because you may have to
create different tags (RC1, RC2,...) from this branch.
good point.
$ svn copy branches/PHP_5_3_1 tags/php_5_3_1RC1
- 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 lostThere 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.
The point is: diffing against the tags/ directory gives a way longer
diff command than diffing against an older revision of the same file ...
while svn is missing the "knowledge" about branches/tags ... that's the
thing where I really like CVS more than svn:
cvs diff -r SOME_TAG file.c
with svn that's either typing the full URL or tons of "../". And the
idea now was to simplify such a diff.
johannes