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:lesmikesell_at_gmail.com]
Enviada em: sexta-feira, 29 de outubro de 2010 14:00
Para: users_at_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
lesmikesell_at_gmail.com
Received on 2010-10-29 19:22:57 CEST