Hi David,
Thanks for the response, IMHO Perforce is conceptually comparable to
Subversion but naming conventions probably differ and I agree we should
follow the ones for Subversion, but as my knowledge with Subversion is
not beyond obtaining sources from it I hope others will translate the
concept in correct Subversion vocabulary.
In the naming scheme you provided it is not completely clear yet where
you would work for the various stages, so let us give it a try with the
given scenario.
Say we are feature ready for version 3.0 of River and we want to provide
support for 3.0 (bugfixes and maybe small features) while we are going
to work on version 3.1 as well. I would say we branch:
/trunk 'branch into' /tags/release_3.0
After release 3.0 is really ready (stabilized) for an official release
we do:
/tags/release_3.0 'branch into' /tags/release_3.0.0
All features for the next release (3.1) are developed in the /trunk or
some experimental or whatever branch. But it turns out there are some
bugs in the 3.0.0 release. Fixing those bugs are conducted in the
/tags/release_3.0 until we believe we are really ready for the 3.0.1
release. When ready we branch:
/tags/release_3.0 'branch into' /tags/release_3.0.1
And so on, and so on. If it turns out we are fixing bugs for 3.0.1 that
are also a bug in the trunk we integrate the fixes from the
/tags/release_3.0 into the trunk:
/tags/release_3.0 'integrate into' /trunk
If it turns out that in the trunk we fixed a bug that needs to get into
River 3.0 we integrate the relevant fixes from trunk into the
/tags/release_3.0 branch and from there in the 3.0.2 branch:
/trunk 'integrate into' /tags/release_3.0
/tags/release_3.0 'branch into' /tags/release_3.0.2
In the above I have no clue whether you should use the integration
features of Subversion or that you cherry-pick manually and just apply
the fixes to a certain branch. I know SVN doesn't track integration
history so with regard to a lot of integration work it is pita anyway :-(
David Parry wrote:
/tags/release_2.1
/tags/pre-release_2.1
/tags/release_2.1.1
...
where the second level is whatever naming scheme you find suitable.
Personally I find it becoming crowded in the /tags branch (as I can see
with many ASF projects) and not very expressive so I would opt for
introducing subdirectories to make a difference between a branch that
takes development and one that merely represents a 'label' of a final
release.
If I didn't get something please correct me, I'm a virgin with good SVN
practices ...
--
Mark
