[thelist] Subversion - Multiple Concurrent Projects

[Lee Kowalkowski]

2008/4/9 Chris Marsh <chris.marsh at priocept.com>:
>  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.

That's the problem.  Now the trunk no longer contains the live version
of the code.  Most Version Control Systems allow you to make a
baseline to roll back to later.  It would be better if that wasn't
part of your normal routine though.

Ideally the route to your staging environment ought to be direct from
your branch.  Each branch potentially represents version n+1 of your
live system.  Your deployment to staging needs to be a flexible
arrangement.

>  At the very least I foresee problems where branch A is merged into the
>  trunk, then the business decides *never* to release branch A.

Yes that's a problem, because it contradicts having the trunk as a
represention of the live system.  Suppose you had a high-priority
defect whose must go live ASAP - where's the live version of the code
you need to edit?  How do you even investigate defects if there's
nowhere in your source code repository that truly reflects what's
currently live?

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

Every time a delivery is made to the trunk, all undelivered branches
require merging as soon as is convenient.  This can seem like entropy
and certainly causes disruption.  You need to do all your pre-live
testing in your branch before merging it back with its origin, even
business acceptance testing.

-- 
Lee