Short answer: Try asking www.cmcrossroads.com for help. Your question
is more about software configuration management than version control.
>> We may even have something in QA when an emergency fix needs to go
into production.
Translation: We test a 1.0 patch in QA even if QA is on 2.0.
Is there any reason why you cannot install 1.0 into QA, test the
patch, and then re-install 2.0? The inability to re-load QA with the
prod baseline for prod patch testing (or of having a separate prod test
environment) isn't something that's fixable by a version control system.
>> We would like to be able to reflect our development, QA and
production environments in Subversion, or at least be able to tell what
is in each environment at any given time. Is there an alternative to
having separate development, QA and production branches?
How do you deliver code? Do you deliver releases? If so, then
you should know that 1.0 is in prod and that 2.0 build 150 is in QA.
Meaning, you should be delivering baselines (tag them) to environments.
If a release passes QA, then it gets deployed to prod. You would only
need a single branch to support this (aka trunk.)
You build revision 123 and deliver it to QA. QA blesses 123 and
123 is deployed to prod. If 123 fails, dev tries to fix it in the next
release to QA. The branch looks like:
-------123---->
123 is delivered to QA on Monday.
123 passes QA on Wed.
123 goes to prod on Fri.
You would use short lived branches for prod fixes or QA fixes (in case
you need QA fixed now and can't wait for the next release.)
>> Is there an alternative to having separate development, QA and
production branches?
However, it sounds like you are delivering a lot of little
patches to QA and that the patches go out in random order to Prod. In
this case, you will need one branch per environment since you're
deploying a unique set of patches in unique combinations to dev, QA and
prod. Ex: patches 1, 2, and 3 are in Dev. QA gets them in the order
of 2, 1, 3 over 3 days. 3 passes QA and goes to prod. 1 fails. 2
passes QA a day later and goes to prod. The branches look like:
dev ---1---2---3--->
QA ---2---1---3--->
prod ---3---2-->
Order matters. You need the three branches since the order you deliver
code is important (if foo.jsp includes code from 1 and 3 you cannot
deliver 3 without 1 and vice versa.) There could also be
interdependencies between patches (ex: 1, and 2 rely on DB changes in
3.) This is why you need to maintain one branch per environment with
little patches.
Each little patch can be thought of as a full release. Try assigning
release numbers to each patch, move each release through dev, qa, and
prod, and you'll see the problem and see why you need so many branches.
Long story short, it's not a branching or merging or repository layout
problem, it's a process problem. Subversion can support your process,
but it is your process that determines how many branches and how much
merging is required.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 16 20:41:03 2006