[thelist] Subversion - Multiple Concurrent Projects

Lee Kowalkowski lee.kowalkowski at googlemail.com
Wed Apr 9 05:57:55 CDT 2008

2008/4/9 Chris Marsh <chris.marsh at priocept.com>:
>  This works pretty well when the work requests and projects are released
>  in the same order that they were commissioned. However we now have a
>  backlog of releases, which are being requested out of order. This means
>  that the method of identifying code to be released no longer works
>  automatically, as files in a given branch that have not been altered in
>  the lifetime of this branch actually contain changes from another branch
>  (introducing dependencies on code that is not included in the release).
>  There is also the issue of files that have been changed in multiple
>  branches being released in the wrong order, resulting in regression
>  errors.

I'm not a subversion user (ClearCase, unfortunately), so my terms may
be a little general.

It sounds like you have made two branches from a trunk (e.g A then B),
but you now want to deliver B before A?  Or did you make branch B from
branch A?  Getting this right can be tricky, if you are developing
component X and a separate component Y, then branching off the trunk
is normal.  If you're developing component X and subcomponent X.Y
(which must be delivered with X), then branching from a branch is
normal (if at all necessary).

I'm assuming two branches (A & B) from a trunk, as you wish for an
arbitrary order of delivery.  This prevents dependencies (as no
activity in branch A affects branch B and vice versa), therefore both
branches are potential candidates to become the next version of the
live system.  When the next version of the live system is released,
all branches need updating.

The trunk is always considered the "live" version of the system.
Therefore if delivering branch B first, deliver it as if branch A
didn't exist.  After a successful delivery, the trunk contains the
changes applied in branch B, and the trunk then needs merging with
branch A at some point before its delivery (whenever is most
convenient - preferably not last minute).

Hopefully that helps at least a little. Assuming branch A will be
delivered before B can make it tempting to put important, unrelated
fixes into branch A, this makes things really difficult when that
assumption fails, better to put them into a separate branch of their


More information about the thelist mailing list