Right. when I merge, I use a specific format for the checkin commits.
Is that what your scripts do (so they essentially track the changes
merged by the checkin comments?)
On 11/15/06, Thomas Wicklund <wicklund@eskimo.com> wrote:
> 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
> >
>
--
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 Fri Nov 17 21:28:01 2006