[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
John Clarke wrote: > > JC Question 1>: Step number 5 troubles me - why can this branch NOT be > merged back into the trunk (and deleted) once a release has been taken > and rolled out? (I know it could be done, but just need to know why > they suggest keeping the branch hanging around for so long). > The problem I see is that after a while I could have loads of branches > lying around that if I find a bug somewhere in the trunk later on - I > have to merge it back to all the branches that exist ? (whether they > are "active in production" branches or branches like this that are for > release purposes. You don't have to merge the fix back in to branches you don't care about (i.e. that you don't intend to release). Branches aren't expensive to maintain from a technical perspective - so don't worry about old branches as long as everyone can readily identify why a branch exists, and if it still needs to be maintained. What is the procedure currently followed for maintaining released versions of the projects? Is the procedure adequate? What would people change is they could? Once you've answered those questions you can probably come back to how you could do that in SVN, and what is the best method for implementing it. Having worked as pre-sales techies selling source code management tools well over a decade ago I'm not a huge fan of SVN, reminds me of the 1980's, but unless you have a complex set of releases that need to be tracked, or maintained, people probably don't need hugely complex source code management. And even fairly complex requirements can often be met by suitable procedures and tools that fall outside stick source code management tools. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html