No, checkin comments are arbitrary. The scripts essentially tag the
trunk revision each branch is based on. Each branch consists of a
"base" directory (what it's based on) and a "cur" directory (which is
what you check out and commit to). Merging trunk changes into the
branch consists of merging from "base" to the trunk and replacing
"base" with the current trunk. Merging between branches merges from
"base" to "cur".
The "base" directory avoids the need to keep track of revision
numbers. It also acts like the "label" which has been requested (if I
understand the desire for a "label").
I'm still careful merging back to the trunk -- I check diffs,
especially if I'm merging from a branch off a release branch (a branch
of a branch) back to the trunk.
I see occasional unexpected merge results, obviously proportional to
how far the branch has diverged from the code it's being merged back
into. Normally these result in conflicts.
My concern is keeping multiple branches in parallel. Due to release
cycles I've often got changes which can't be committed immediately, so
I needed a way to keep changes over extended periods until I could
move them to the trunk. These scripts started under CVS using CVS
tags and branches, then rewritten for SVN.
I find some sort of support necessary for SVN. Plain SVN provides the
tools, but no organization. It's unwieldly unless you're doing simple
commits to the trunk. There's too much flexibility, and the command
line is unwieldy with the requirement of full URLs (no simple "-t
name" for a tag as in CVS). Something needs to add some structure and
provide a simple way to find things in the repository. A GUI can
allow browsing and selecting trees (e.g. select two arbitrary points
in the repository and do a diff). For command line tools something
needs to add structure and ideally shorthands to avoid typing long
URLs repeatedly.
Thomas Wicklund
Peter Kahn writes:
> 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 Sat Nov 18 07:34:10 2006