Very interesting. There seems to be a great many branches in your setup.
How do you handle the effort required to merge changes between the
branches?
We had a setup where we had user/private branches and a set of scripts that
merged changes from the trunk to the user branches. It was a bit of a
mess. The speed of updates was a problem as was the issue with conflicts
between branches. We changed to having the user's workspace/sandbox act as
the private branch. A user can initiate a command that grabs his local
changes and sends them to a build machine for a test build. The bundle of
local changes can also be used for a review.
On 11/15/06, Thomas Wicklund <wicklund@eskimo.com> wrote:
>
> 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
>
>
--
Peter Kahn
citizenkahn@gmail.com
citizenkahn@jabber80.com, pkahnpie1@AIM
http://kahnstipation.blogspot.com | http://analogoustendencies.blogspot.com/
Awareness - Intention - Action
Received on Wed Nov 15 21:48:37 2006