The way my organization is supposed to work involves a lot of
branches. The SVN book also talks about simple branching.
Unfortunately SVN provides poor support for branching and merging.
You're either stuck with "svn switch", which is very error prone, or
merging, which normally means remembering revision numbers.
I use a set of shell scripts which handle creating branches and
merging between them (update branch to match trunk or merge branch
changes into the trunk). It also allows merging between release
branches. With the scripts I can maintain a dozen or more branches
without trouble. I wouldn't try it using plain svn or the GUI clients
I've seen.
Thomas Wicklund
Peter Kahn writes:
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 15 23:30:08 2006