[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: bug fixing across many branches

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-10-20 14:07:35 CEST

On Oct 20, 2005, at 13:36, Phil Kingston wrote:

> I've been using Subversion happily here at work for a while now to
> manage
> all our projects, with many users working on many projects. One of our
> projects has several versions (different requirements for different
> clients)
> which we manage with branches. We are about to start working on a new
> version for this project and are potentially going to run into lots of
> branch nightmares.

[...]

> I desperately need a method of being able to apply a change to the
> trunk and
> ALL branches, without having go through the merge sequence every time.

[...]

> Am I missing something?
> Should I be using svn differently?
> Do I just have to put up with the fact that I'm going to have to
> merge a bug
> fix 10s of times each time?
> It has been suggested that we change the architecture of our
> software so
> that we only have one trunk with all the different client's
> requirements as
> options, but that would take a lot longer to implement than finding
> out if
> svn does what I want it to first! ;)
>
> I have also experimented with svn:externals but they don't give the
> sort of
> functionality i'm talking about here.

Subversion won't merge anything automatically. You'll have to tell it
what to merge and when. Merging can resolve in conflicts which would
require human intervention to resolve.

It sounds like you're merging to from trunk to your customer branches
after every change on trunk. Given enough customers and enough
changes, I see how that could get tiresome.

You could merge less frequently. You could develop on trunk, tagging
when you reach milestones. If you have a tag of trunk called 1.0.5
and you make several changes and reach a new milestone, then you can
make a new tag 1.0.6. Customer #1 was already using version 1.0.5 in
their branch. So to update them to 1.0.6, you can go to the working
copy of that branch and svn merge $REPO/tags/1.0.5 $REPO/tags/1.0.6.
Customer #2, also on 1.0.5, maybe doesnt need the features you've
added in 1.0.6, so you do nothing. When the customer decides that
they need the features in 1.0.7 then, you can svn merge $REPO/tags/
1.0.5 $REPO/tags/1.0.7 (going directly from 1.0.5 to 1.0.7).

You do need to keep track of what you've already merged. (You have to
do this now already, it's just that you keep track by saying "I've
merged everything.") But this is done through commit messages. When
you upgrade customer #1 to 1.0.6, your commit message will say so
("Upgrading customer #1 from 1.0.5 to 1.0.6") so that by looking at
the log, you can always determine what version that customer is at,
so you know how to upgrade them to the current version.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 20 14:09:50 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.