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

When defining units of work always try to define them as tightly
focused and as narrow in scope as possible. This shortens the
development time and makes it easier to review the tasks resolution.

You should find that a great many tasks fall into a small enough
time-frame to keep the 'at risk' material to a minimum.

Those tasks that require more time or multiple developers can use a
task-branch that is merged and then deleted at completion (or deleted
once a review is completed).

Branching and merging for each and every task is likely to cost more
in administration time than the risk it mitigates. In fact merging
(with conflicts) is another point at which developers can make
mistakes so you might actually increase your risk but instead be
introducing the risk into the main stream of development (assuming the
cost is in lost developer time and not lost ideas, such as might occur
with developers doing experimental work on their own machines - a
likely case for throwaway branches anyway).

--
Talden
On 5/10/07, Vandenbroucke Sander <Sander.Vandenbroucke@vandewiele.com> wrote:
> > > 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
> It is mainly for the sake of backup. Once committed it is backup-ed.
> Otherwise there is a risk of loosing a great deal of work when a
> developers pc crashes.
>
> > 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.
> >
> What is this model?
>
> ---------------------------------------------------------------------
> 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