CC-ing the list > -----Original Message----- > From: Luiz Guilherme Kimel [mailto:lki...@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.trocc...@uk.linedata.com] > Enviada em: sexta-feira, 29 de outubro de 2010 09:20 > Para: users@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 > > > > >
