First, let me say that I agree with David's suggestion that
we should adhere to the established Subversion convention with
a few minor modifications. However, Mark made a good point about
needing to clarify the life-cycle with regard to branching and
tagging releases.
I have additional responses interspersed below.
On Dec 5, 2007, at 08:17, Mark Brouwer wrote:
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
I'd prefer to see the "tags" area remain a "golden", reference-only
area for official releases to avoid mixing pre-release working
copies with official releases in the same area. If we really
need a pre-release working copy to allow newer work in the trunk,
I'd suggest that we create a release-candidate branch in a separate,
top-level, "release-candidates" directory.
For those who may not be aware, Subversion does not have a labeling
mechanism. Copies from specific repository revisions are used to
create named (ie, "tagged") snapshots. Branches are also just copies.
All features for the next release (3.1) are developed in the /trunk or
some experimental or whatever branch.
"Next release" work in the trunk seems reasonable.
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
In the case of sustained work for previous releases, we could branch
off of a tagged release, placing the working branch in a "sustaining"
directory (eg, sustaining/release_3.0.1_work). When the sustained
work is released, a tagged copy would be placed into the official
"tags" area (eg, release_3.0.1).
Obviously, changes in branches (sustaining work, prototype work, etc)
that also apply to the latest work in the trunk or other sustaining
work can be merged appropriately on an as needed basis regardless of
where the working branches are located.
The release candidates and sustaining branches could easily go into the
"branches" area, but I suspect that area will quickly become cluttered
with all sorts of stuff of varying importance. I'd prefer a few
specific
top-level folders.
To summarize the above, we would have the following:
/branches/ ## misc work
/release-candidates/release_{ver}_candidate
/sustaining/release_{ver}_work
/trunk/ ## "latest" work
/tags/release_{ver} ## only official releases
Moving the "release-candidates" and "sustaining" dirs under "branches"
would also be ok and would maintain the intent of a "branches" area. If
we did this, I'd also make a "branches/misc" area to prevent the clutter
I mentioned above. If we went with this option, the overall layout
would
look like:
/branches/misc/ ## misc branched work
/branches/release-candidates/release_{ver}_candidate/
/branches/sustaining/release_{ver}_work/
/trunk/ ## "latest" work
/tags/release_{ver}/ ## only official releases
Comments?
Frank
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
