Nothing if you don't have concurrent "new features" development lines. If you can predict serial updates, then you won't need to branch. It's the first option, it's less complex: one mainline of development, branching only for emergency corrections from production tags.
But, if you have concurrent development efforts that can be stopped, change in priority, take long time to be validated by a client etc, then I think branching for feature and updating the trunk only with stable code that needs to be spread turns everything easier and cleaner. If you have many different clients for a single product, it may gets hard to know which new feature will be released first. Clients will not always obey to plans and clients may change their mind in what is priority and what is not. -----Mensagem original----- De: Les Mikesell [mailto:lesmikes...@gmail.com] Enviada em: sexta-feira, 29 de outubro de 2010 14:00 Para: users@subversion.apache.org Assunto: Re: RES: Advice on process for web development On 10/29/2010 12:10 PM, Luiz Guilherme Kimel wrote: > Let me try explain it better... > > Let's say I just built the first version of an application, so I don't > currently have any branch, just the trunk where a small team of developers > were working until now. Our last build was tagged as 1.0.0.54 meaning it's > our 54 build of the 1.0 version. The QA team approved this build and it > becomes our first release of the software. Tag 1.0.0.54 is our baseline > which is equal to our trunk at that moment. > > Now we have two new modules to develop in parallel. The team will receive > more people to speed up next releases, so we decided to start working with > branches. Two new branches are created: /branches/1.1a and /branches/1.1b. > Trunk is locked. Only reading is allowed. Developers are allowed to write > only on branches. What do you gain by making 2 branches instead of continuing one line of development on the trunk and the one that would be disruptive to it on a branch? -- Les Mikesell lesmikes...@gmail.com
