On 10/29/2010 9:04 AM, Giulio Troccoli wrote:
>
>> Sometimes your baseline will evolve. Maybe because your QA
>> team approved some new features for production, maybe because
>> you made urgent corrections.
>> If it's approved for production it will be your new baseline.
>> All branches from this baseline will need to be "rebased"
>> before releasing, they need to incorporate any production changes.
>
> So, basically, I need to merge changes in trunk from the previous "production" revision to the current "production" revision (which may not be HEAD at all) to the branches.
Or just make different 'cuts' from the trunk to new QA branches, which,
if everything works can be copied unchanged to production tags. If you
have to make changes in QA, you have to make an additional decision as
to whether the fix needed there also applies to the ongoing trunk, and
if so, merge it - or maybe it has already been done on the trunk.
>> Why your QA team have a branch??? They won't ever make
>> changes, so all they need is a tag. I mean, in SVN it's the
>> samething, but in the concept it's a lot different.
If things never change between the cut from trunk and the production
release, what's the point of the QA step? It is possible, in fact
likely, that you'll need changes for a release after the trunk has moved
on to include things you don't want in this release.
> The QA team does not have a branch. I realised I said "create a QA branch as a copy of trunk" but then in the command I did create the "branch" in tags. Which doesn't mean that they cannot change it, but it will be prevented and, as you said, conceptually is different.
If you made a tag for QA you can always copy it out to a branch after
discovering it needs changes.
> Thanks for your input, however, you haven't touched on the main issues I have, which is about the case of an urgent fix.
If you had a QA branch corresponding to each release, you'd have an
obvious place to make maintenance fixes specific to that release. But
that doesn't solve your problem of making sure the fix also is done in
the trunk - unless you do the work on the trunk and merge to the branch
to add the fix. How you do that needs to be a human decision, not
driven by the process. If the process could solve all your problems you
wouldn't need this urgent fix in the first place, you'd have caught it
in QA. Since it is something unexpected, you need to understand it and
figure out separately how it relates to the now-different trunk.
--
Les Mikesell
lesmikesell_at_gmail.com
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-10-29 16:53:53 CEST