[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Branching/Merging Best Practices

From: Lakshman Srilakshmanan <lakshman.srilakshmanan_at_tradingpost.com.au>
Date: 2006-07-18 01:36:38 CEST

Hi Rob,

Yes, we do use tags. We use tags to reproduce an earlier production
release. In our case the trunk/HEAD and the latest tag will always be
the same.

I don't quite agree with the statement there is no "best practice" for
branching.

I would probably say there are different branching policies based on
your requirement.

For example, you may dirty your trunk if you don't have a requirement
for multiple stream development. We have multiple projects sharing the
same "base code", as stated in my previous e-mail, it is the
responsibility of the project team lead to bring their branches up
todate ie incorporate any bug fixes/enhancements that may have been
released. In this setup we cannot have trunk polluted with
non-production code. Trunk represents a stable release from where other
projects can receive updates.

This is different to refactoring. In a number of emails I find branching
associated with refactoring. If you don't have multi-stream development
then using trunk for development is easier, without the need for the
overhead complexity and rigorous associated with branching and merging
in multi-stream development. In this environment branching only for
refactoring makes sense.

Thanks
Lakshman

> -----Original Message-----
> From: Rob Wilkerson [mailto:r.d.wilkerson@gmail.com]
> Sent: Monday, 17 July 2006 9:34 PM
> To: Lakshman Srilakshmanan
> Subject: Re: Branching/Merging Best Practices
>
> Thanks, Lakshman. That leads me to wonder, then...do you use tags for
> any purpose? I had intended to use tags to recreate my production
> environment. For me, "production environment" means any given release
> of the product. My understanding - at the risk of oversimplification
> - was that branches "should" support development while tags "should"
> support production. IOW, branch to develop and tag to mark releases.
>
> It doesn't appear that there really is a "best practice" that has been
> so widely adopted as to be considered the standard, but the feedback
> I've gotten from this thread has really helped me think about some
> things that may not have occurred to me until after it was too late.
>
> Thanks.
>
> On 7/17/06, Lakshman Srilakshmanan
> <lakshman.srilakshmanan@tradingpost.com.au> wrote:
> > Hi Rob,
> >
> > Allow me to throw another spanner into the work.
> >
> > We use trunk as sacred.
> >
> > All our development/maintenance/support is done from branch.
> >
> > When a bug gets fixed (on the support branch) it gets merged into
trunk
> > prior to release.
> >
> > The team leads for each branch are responsible to merge these
changes
> > into their respective branches. This ensures that the branches
always
> > have the latest trunk.
> >
> > The reason we treat trunk as sacred is because we can at anytime
rebuild
> > our production environment from trunk.
> >
> > Hope this helps.
> >
> > Thanks
> > Lakshman
> >
> >
> > > -----Original Message-----
> > > From: Marc Haisenko [mailto:haisenko@comdasys.com]
> > > Sent: Wednesday, 12 July 2006 8:48 PM
> > > To: users@subversion.tigris.org
> > > Cc: Rob Wilkerson
> > > Subject: Re: Branching/Merging Best Practices
> > >
> > > On Wednesday 12 July 2006 12:36, Rob Wilkerson wrote:
> > > > Sorry, I accidentally sent this directly to Nick. Hopefully
this
> > time
> > > > it will go to the entire list.
> > > >
> > > > ==================================
> > > >
> > > > Thanks, Nick. That makes a lot of sense and is the exact
opposite
> > of
> > > > how I was thinking of things. I'm glad I asked. If I
understand
> > > > correctly, then at any given time there may be development
actively
> > > > ongoing against the trunk and one or more branches. For some
reason
> > I
> > > > was thinking that the trunk was sacred. I have no idea why.
> > >
> > > There are a few ways of working with branches. One is "trunk is
dirty"
> > which
> > > means that the trunk always contains the latest changes and you
branch
> > off
> > > stable branches from it.
> > >
> > > Another is "trunk is stable" which means that development takes
places
> > in
> > > branches and you then merge your stuff to trunk when you think
it's
> > stable.
> > > In this type trunk IS sacred ;-)
> > >
> > > You can do both with SubVersion, pick the one that suits you best.
> > >
> > > We do it like Nick here, and only do branches for bigger changes
where
> > we know
> > > it'll take a few commits until stuff will work and in the meantime
our
> > system
> > > would be broken. By making a "working branch" we can break as much
as
> > we want
> > > without interfering with the developers working on trunk. But it's
not
> > > necessarily the best development method for you as well, you need
to
> > decide
> > > for yourself.
> > >
> > > > Let me ask one follow up question to see how you'd handle the
> > scenario
> > > > I'm about to face...once I import my current stable version and
> > create
> > > > a branch for that version my trunk will look exactly the same as
> > that
> > > > branch. For the next version, though, the code base will be
> > entirely
> > > > reorganized - new folder structure, pathing, etc. Should I do
that
> > > > work directly on the trunk or is that something so massive that
it's
> > > > better handled on a branch? How are major overhauls like this
> > handled
> > > > in other shops?
> > >
> > > I've done things like this in trunk so far, but just because I was
the
> > only
> > > one to do such things and was the only developer working that day
(we
> > were
> > > small back then) so I knew I wouldn't interfere with others.
> > >
> > > Doing a branch for such things may be a good idea, but be prepared
for
> > some
> > > conflicts when merging if others changed stuff on trunk while you
> > reorganized
> > > in your branch. Hard to say for me which is the best method for
you..
> >
> >
>
>
> --
>
> Rob Wilkerson

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 18 02:07:04 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.