[thelist] Subversion - Multiple Concurrent Projects

[Chris Marsh]

Lee

Thanks for the response.

> 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

[..]

> 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

More accurately as things stand, branches A, B, C, D and E have all been
created from the trunk, at different times. All of these branches have
also been merged back into the trunk at different times - this is
required to get changes onto our staging environment for business
validation. This means that some of the branches may (or may not,
depending on when they were branched) be polluted with code produced in
other branches but not yet released.

[..]

> 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).

I understand this in principle, but I'm not sure how to modify our
process so that:

1. We can get changes from branch A to a staging environment for
business validation.

2. The order of release for branches A and B can be arbitrary.

3. Branches A and B can be shelved for a long period of time.

At the very least I foresee problems where branch A is merged into the
trunk, then the business decides *never* to release branch A. If the
trunk represents the live system, how does one de-merge branch A? Also,
in terms of the trunk representing the live system - I do not see how
entropy would not result in certain de-synchronisation over time.

> 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
> own.

I certainly does help, thanks. I also agree that changes should be
included in branches for logical not time-related reasons.

Thanks again!

Chris Marsh
chris.marsh at priocept.com

Tel: +44 (0)1344 845454
Mob: +44 (0)7920 461192
________________________________________________________________________

Confidentiality notice: 
This email and/or any attached document(s) is confidential and intended
only for the person to which it is addressed. It may contain privileged
and/or confidential information. Any review, retransmission,
dissemination or other use of this information by persons other than the
intended recipient is prohibited.
________________________________________________________________________