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
I don't quite agree with the statement there is no "best practice" for
I would probably say there are different branching policies based on
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.
> -----Original Message-----
> From: Rob Wilkerson [mailto:firstname.lastname@example.org]
> 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.
> On 7/17/06, Lakshman Srilakshmanan
> <email@example.com> 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
> > prior to release.
> > The team leads for each branch are responsible to merge these
> > into their respective branches. This ensures that the branches
> > have the latest trunk.
> > The reason we treat trunk as sacred is because we can at anytime
> > our production environment from trunk.
> > Hope this helps.
> > Thanks
> > Lakshman
> > > -----Original Message-----
> > > From: Marc Haisenko [mailto:firstname.lastname@example.org]
> > > Sent: Wednesday, 12 July 2006 8:48 PM
> > > To: email@example.com
> > > 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
> > time
> > > > it will go to the entire list.
> > > >
> > > > ==================================
> > > >
> > > > Thanks, Nick. That makes a lot of sense and is the exact
> > of
> > > > how I was thinking of things. I'm glad I asked. If I
> > > > correctly, then at any given time there may be development
> > > > ongoing against the trunk and one or more branches. For some
> > 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
> > which
> > > means that the trunk always contains the latest changes and you
> > off
> > > stable branches from it.
> > >
> > > Another is "trunk is stable" which means that development takes
> > in
> > > branches and you then merge your stuff to trunk when you think
> > 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
> > we know
> > > it'll take a few commits until stuff will work and in the meantime
> > system
> > > would be broken. By making a "working branch" we can break as much
> > we want
> > > without interfering with the developers working on trunk. But it's
> > > necessarily the best development method for you as well, you need
> > 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
> > > > work directly on the trunk or is that something so massive that
> > > > 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
> > only
> > > one to do such things and was the only developer working that day
> > 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
> > 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
> Rob Wilkerson
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jul 18 02:07:04 2006