On Thu, 2006-11-09 at 11:13 +0000, Gundersen, Richard wrote:
> > If all development is done on one trunk branch, then at some point I
> have to
> > tell Germany that because Spain MUST have their change, I have to
> release
> > their change too. I know what will happen - Germany will stop using
> the
> > system.
>
> >>>That's only true if you add an unnecessary constraint that your
> >>>releases have to be directly from the trunk. If you tag/release
> >>>from branches you can support any number of versions concurrently.
>
> =============================================================
> I'm not sure I understand. I want to keep these two changes separate
> from each other so they can be released independently. If they are both
> developed on the trunk, I can't separate them.
Of course you can. Branch/test/tag a release that you can maintain
without any changes, add one of the new developments to the trunk,
branch/test/tag, add the other, branch/test/tag all more or less
independently of time except for the order of adding to the trunk
and making the branch copies.
> Are you saying have a
> release branch for each change? In order for them to remain separate,
> development for each change would have to START on the release branch.
I'm saying a release branch for each planned release which may or
may not have more than one change. The branch can start as a copy of
the trunk at a point when it is ready for QA with the current
addition(s).
That way the trunk accumulates all work that is expected to be included
in future versions, the branches give you a place to finalize and
perform maintenance that relates only to a specific release. If you
do a good job of adding features to the trunk in the right order and
copying the release branches at the right time you minimize the extra
work.
> If the release branch this development started on was for another
> release that had already been agreed (it contains other functionality
> too), that release will have to wait until the development of the
> feature is finished, otherwise the release will include unfinished work.
I don't follow that. If you plan releases from their own branches
nothing
has to wait for anything else. But if you find in testing that your
release branch needs substantial changes that other releases should
include you can always merge back to the trunk - or have the developer
put it on the trunk and merge to your branch. As someone else
mentioned,
making features optional at run-time can let you include them in the
mainstream development even if they aren't used everywhere.
> If this is the only reason for having the branch, it's a feature branch.
The main reason is to allow work concurrently on different releases,
both in the final development and maintenance phases. Meanwhile
you need somewhere else to accumulate development towards the next
release.
> And what's more, it might have been branched off an unstable trunk that
> was in no fit state for production.
You still haven't described the problem an unstable trunk might
cause for you. You have to test/stabilize somewhere leading to
the tag copy for release. Doing that on the trunk means you
can only do one version at a time. Using branches lets them
overlap. There's really not much difference otherwise besides
name conventions. The only problem I'd expect from an unstable
trunk would be if you permit access by people who don't know
where to find the stable branches/tags.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 17:13:51 2006