CC-ing the list
> -----Original Message-----
> From: Luiz Guilherme Kimel [mailto:lkimel_at_dba.com.br]
> Sent: 29 October 2010 15:44
> To: Giulio Troccoli
> Subject: RES: Advice on process for web development
>
> Giulio,
>
> I would recommend you a reference book for SCM patterns. Try
> ADDISON WESLEY Software Configuration Management Patterns. It
> has solutions
>
> Answering your questions, you need to stablish baselines for
> your software.
> Branches will have one baseline as their common start point,
> as their "base". This base will usually be a stable version
> of your software. Let's say your baseline is exactly your
> current production release.
What you're saying is that the branches should be created as copies of trunk at a specific revision, i.e. the production one. Have I understood correctly?
> 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.
> Your correction will be tested isolated, approved and merged
> to your trunk for tagging and release. If your development
> branches are based on the trunk, then you will need to merge
> trunk changes to each development branch to rebase them. Use
> the development branch for integration so that the next
> approved branch will always merge to the trunk with no
> possibility of conflict. After rebasing, apply new QA tests.
I'm not sure I understand you here.
After the development in a branch has been completed, the branch is tested and if approved merged back into the trunk. Surely though I need to test trunk as well. I didn't say, but yes when a branch is reintegrated into the trunk, the other branches should merge from trunk to get those changes.
> 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.
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.
> Do you already use any project management and bug tracking
> tool? If not, I would recommend MantisBT.
We do. It's actually part of what the Web Team does.
Thanks for your input, however, you haven't touched on the main issues I have, which is about the case of an urgent fix.
Giulio
> Best Regards,
> Luiz Guilherme M. Kimel
>
>
> -----Mensagem original-----
> De: Giulio Troccoli [mailto:Giulio.Troccoli_at_uk.linedata.com]
> Enviada em: sexta-feira, 29 de outubro de 2010 09:20
> Para: users_at_subversion.apache.org
> Assunto: Advice on process for web development
>
> Hi,
>
> I'm working with our Web Team to re-engineer their
> development process. All the code is already under
> Subversion, but everything is in one big directory. They're
> not using any branch or tags for that matter. And of course,
> testing is not as rigorous and controlled as it should be.
> Anyway, I have suggested the usual trunk/branches/tags layout.
>
> Developers will normally work on branches, but can
> occasionally work directly on trunk for easy and quick fixes.
> The tester will create a QA branch as a copy of trunk at a
> specific revision. When they are happy that a QA is ready for
> releasing, a tag is created from the QA (or maybe from trunk
> again at the same revision).
>
> I think they will go for such a solution, even though it
> means that they cannot pick-and-choose what to test. If they
> want to test a bug fixed in revision 1000, they will also
> test all bugs fixed in previous revision.
>
> The problem is that they may want to fast track an urgent bug
> fix. It shouldn't happen often, but it may happen so I need
> to come up with a solution for that case too.
>
> What I'm thinking is something like the following. Let's
> supposed that 1.1 is the latest release, i.e. it's what's in
> production.
> i) the developer creates a branch off the tag
> svn cp http://<URL TO REPO>/tags/1.1 http://<UR TO
> REPO>/branches/1.1_urgent_fix -m"Creating branch fro urgent
> bug 123456"
> ii) the developer makes all the necesary, coding and testing
> iii) the fix is merged back to trunk
> cd trunk
> svn merge ^/branches/1.1_urgent_fix .
> svn ci -m"Fixing urgent bug 123456"
> iv) the branch goes live
> svn cp http://<URL TO REPO>/branches/1.1_urgent_fix
> http://<URL TO
> REPO>/tags/1.2 -m"Fixed bug 123456"
> switch the production site to point to ^/tags/1.2
> v) at this point all the QA are useless because the do not
> contain the urgent fix, so a new QA must be created
> svn cp -rHEAD http://<URL TO REPO>/trunk http://<URL TO
> REPO>/tags/QA_1.3_1 -m"Created first QA for 1.3"
>
> Now my questions.
> 1 - Do you have any comments on the process and/or any suggestions?
> 2 - Would the merge, in step iii, do the right thing and
> merge all revisions committed into the branch into trunk? I
> can't use --reintegrate becuase I haven't previously merged
> from trunk to the branch (as the branch was created as a copy
> of a tag).
> 3 - I don't really like the fact that after the fix has gone
> live, we are forced to create a QA from HEAD, which means
> testing everything that has gone into trunk, but I can't
> think of another way to make sure the fix is indeed included
> in the Qas and especially in the next (1.3 in this case) release.
>
> Thank you in advance.
>
> Giulio
>
>
> Linedata Limited
> Registered Office: 85 Gracechurch St., London, EC3V 0AA
> Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
>
>
>
>
>
Received on 2010-10-29 16:05:41 CEST