subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giulio Troccoli <>
Subject RE: Advice on process for web development
Date Fri, 29 Oct 2010 14:04:59 GMT
CC-ing the list 

> -----Original Message-----
> From: Luiz Guilherme Kimel [] 
> 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.


> Best Regards,
> Luiz Guilherme M. Kimel
> -----Mensagem original-----
> De: Giulio Troccoli []
> Enviada em: sexta-feira, 29 de outubro de 2010 09:20
> Para:
> 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
View raw message