>- see footer for list info -< Ok here is what we do. Each project in SVN has the following sub folders
svn/projectname/trunk/[project folders] svn/projectname/branches/branchname1/[project folders] svn/projectname/tags/tagname1/[project folders] This is a very standard setup and you will find that some tools assume this structure. the latest revision in trunk matches our live code. For each distinct peice of work allocated to a developer (even if it is small) we create a branch under the branches folder (in SVN it only actually creates some pointers and then records the changes you make rather than a full copy). For us the branch name matches our issue/bug tracking system reference for easy cross reference. A branch is created from trunk so its a copy of the live code at that moment. One or more branches are worked on and tested by the developers on their own PC's in isolation from other developers work. When they are happy that it works for them, that branch is deployed to a staging environment. The beauty here is that this is live + plus one specific code change related to a specific issue/bug reference, so can be tested cleanly without any worrys of contamination from other coding work that may be going on. If that test passes it is ready to be combined into the next release candidate (RC) branch. So when we feel there are significant changes to release we create a RC branch named usually after some version convention e.g. RC1.2.3. We then merge in all the branches that have passed branch testing. The merge tools in Subclipse will show a graphical diff of the code and highlight any conflicts but 90% of code merges with no conflicts. The RC branch is then deployed and all the issues combined into that release are re-tested, plus some regresssion testing to make sure it has not broken existing code. Onec all that is OK (and if we find errors developers work directly on the RC branch with the combined code), the RC branch is merged back to the trunk. Trunk is then tagged creating a fixed point in the repository for this release. That tag is then deployed to live/production. If any problems crop up on production then you can quickly re-deploy the previous tag. Hope that helps. On 10 August 2010 14:48, rex <[email protected]> wrote: > - see footer for list info -< >> > I'd like an outline please. Merging has always been a pain for our team, > so I'd like to know how people's SVN workflow are, and I'm very much open > to suggestions. Thanks! > > > Michael Traher wrote: > >> It is useful to adopt a branching and release strategy once you are up and >> running with SVN and if you are interested I can outline what we use here, >> although there are several different ways to approach it. >> >> >> > > _______________________________________________ > > For details on ALL mailing lists and for joining or leaving lists, go to > http://list.cfdeveloper.co.uk/mailman/listinfo > > -- > CFDeveloper Sponsors:- > >> - cfdeveloper Hosting provided by www.cfmxhosting.co.uk -< >> - Lists hosted by www.Gradwell.com -< >> - CFdeveloper is run by Russ Michaels, feel free to volunteer your help -< >> > -- Regards Mike _______________________________________________ For details on ALL mailing lists and for joining or leaving lists, go to http://list.cfdeveloper.co.uk/mailman/listinfo -- CFDeveloper Sponsors:- >- cfdeveloper Hosting provided by www.cfmxhosting.co.uk -< >- Lists hosted by www.Gradwell.com -< >- CFdeveloper is run by Russ Michaels, feel free to volunteer your help -<
