Well, the convention with Subversion is:
/trunk
/branches/experimental_version
/branches/new_feature_integration
...
/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.
where the branches are used to work "in isolation" for a while, before
merging with the trunk, and the tags are usually for something like a
complete snapshot of a working version that you want to be able to
refer to.
I have found that comparisons between version control systems and
their different strategies can be very confusing. As such, I think
introducing Perforce principles are not going to map so well. Since
Subversion is the version control system in use, better to stick with
the typical practices for it.
On 05/12/2007, at 6:53 PM, Mark Brouwer wrote:
Jim,
The release notes look good to me. There are some HTML bugs in this
file that I can fix if you like, let me know if you want me to do it.
Given the fact many committers are grabbing their piece of work as
JIRA shows I really think it is time to branch into a version or
release branch, or are there some things that needs to be done and
that would be a pain to integrate back into the trunk?
About branching I believe we should come up with a strategy for
branch names and code evolution. Based on perforce (which has better
integration support, so I might be wrong for SVN) I opt for a main
branch (the trunk) which should contain the ongoing and latest and
greatest development.
/trunk/
/version/2.1/
/release/2.1/1/
/release/2.1/2/
The version/2.1/ branch is branched from the main branch (which we
could do now), the release/2.1/1/ and release/2.1/2/ branch are
branched from the version/2.1/ branch.
This way we can provide support in the version/2.1/ for the 2.1.x
releases and allows us to make more (temporarily) disruptive changes
in the trunk. Emergency fixes for a particular release branch can
always applied to the release branch itself without being interfered
with work in the version branch. We can always integrate changes
from trunk into version if there is a need, or the other way around.
I also think we should change AR1 to AR_2.1.1 in JIRA.
Let me know what people think. I can be a bit more verbose related
to the branching policies from a conceptual viewpoint but I hope the
above is clear.
--
Mark
