Jim Reynolds writes:
> I am trying to locate some type of SOP for software releases.
>
> If I have some software in the trunk, and I want to do a release
> build, should I tag what we have, or should I branch what I have?
Personally, I think that the "rule" that you need trunk, tags, and
branches top level directories doesn't make sense. Why provide a file
system which allows arbitrary copies, and then tell you it must be
organized as if it were CVS?
I'd organize the repository the way your organization works. For
example, in my own work most development is on a trunk revision.
Releases of code for a product are done periodically. A release is
branched from the trunk for final testing, with only bug fixes going
into the release (while development on the trunk can continue
uninterrupted).
Builds are done for both the trunk and releases. The compiled "build"
is what the test organization uses for testing.
Developers are supposed to create private branches, make changes, get
them reviewed, and then apply the changes to the applicable release(s)
and/or trunk. There are also some feature branches for development of
major features (though personally I prefer a conditional build rather
than leaving code branched for extended periods, merging the branch
after months of changes is highly error prone).
If I were running things (which I'm not), I'd organize a repository
something like:
/repository
/trunk
/release
/build
/users
The "trunk" directory contains main development code.
The "release" directory contains a sub-directory for each release. It
might be organized as a single directory, a directory per product, or
whatever makes sense.
The "build" directory similarly contains a sub-directory for each
product build. The builds could be in a single directory or under
some logical directory structure.
The "users" directory contains a sub-directory for each developer.
Developers can do whatever they want within that sub-directory.
An advantage to this structure is that you know at a glance which is
"official" code and which is not. My company currently uses the
trunk/branches/tags structure and the "branches" directory has 19
entries, one of which is a release branch while the rest are private
user branches. Thus an official branch is identified by knowing ahead
of time the name of the official branch.
I'm not suggesting anybody use the structure I presented here. Figure
out how your own organization works and structure the repository to meet its
need. Some organizations only need to take periodic builds from the
trunk (this applies to many open source projects). Some organizations
require that all changes be committed against a bug/feature request in
the defect tracking system. That organization may define a top level
"issue" directory with issue number sub-directories under which
development branches are created.
Thomas Wicklund
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 15 20:31:12 2006