Re: [Fwd: Re: Branches? How many?]

I'm wary of any strategy that fails to encourage brevity in work tasks.

There are costs to using a task branch for each and every task (I
prefer task rather than feature, bugs are not features), especially if
it opens up the temptation to make tasks less fine-grained...

1. Features are delivered to the trunk later - less exposure to other
developers.

2. Features can be harder to review - the changes are larger and their
purpose is less focused.

3. There is a higher likelihood of conflicts - the longer a developer
works away from the trunk the more likely trunk changes conflict with
changes on their branch.

4. You end up with a more complex revision history - many more merge
situations mean many commits that are just administration commits
moving work from a branch to the trunk. Of course merge information
from later subversion releases will make these commits more
expressive.

There are arguments in favour of a branch for every task of course...

1. Task branches can be named by ticket number - easier to find than
revisions with ticket number commit messages - though if you close
branches (deleting the branch) you still need to peruse the commit
messages to find out when the branch was closed.

2. Incomplete work can be checked in, and multiple developers working
on the same ticket can share content without interfering with other
development.

In the end, as long as you've worked out the process and everyone
understands it, either approach will work... You just need to be
aware, and comfortable with, the trade-offs.

--
Talden
On 5/11/07, Chris.Fouts@qimonda.com <Chris.Fouts@qimonda.com> wrote:
>
>
> >-----Original Message-----
> >From: Stefan Langer [mailto:mailtolanger@googlemail.com]
> >Sent: Thursday, May 10, 2007 5:04 AM
> >To: subversion
> >Subject: [Fwd: Re: Branches? How many?]
> >
> >Forgot to include the list in the reply!
> >Vandenbroucke Sander schrieb:
> >
> >> Hi,
> >>
> >> We are working with SVN for a couple of months now but we're
> >not quite
> >> on top of it.
> >> What we struggle with most is a good branch policy. Now we
> >have each a
> >> branch in which we do our daily development for new features as well
> >> as for bug fixes. When things are tested they get merged into trunk.
> >> This leads to many intermediate commits to our branches in
> >order to be
> >> able to merge a small bug fix to trunk without merging any ongoing
> >> work on a new feature.
> >>
> >> Apart from bug fixes and new features we also have 'test software'.
> >> This is highly experimental software mainly to be able to trace and
> >> diagnose bugs. Most of these tests get obsolete once the bug
> >is fixed.
> >> Some stay alive.
> >>
> >> Any ideas on how to handle this situation?
> >>
> >> Sander.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> >> For additional commands, e-mail: users-help@subversion.tigris.org
> >>
> >>
> >>
> >Why the need for every developer to have a separate branch?
> >Let all work on the trunk and just use branch for releases and
> >experimentell stuff.
> >After all having more than one developer work on the same code
> >base is what subversion is all about. If you need greater
> >controll use a checkin checkout model.
> >
> >Regards
> >Stefan
> >
> >
> >
>
> I like the idea of developers having their own branches, so they
> can commit their work without affecting others.
>
> A compromise to having private branches and developers committing to
> trunk is to have an integration branch off the trunk, which developers
> can do their work on.
>
> To the OP, I don't see an issue to how you're using SVN; that's exactly
> how we're using it; of course we only have 4 developers in my group) so
> we're able to manage it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org