[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: Ashutosh Mohanty <ashutosh_at_syncad.com>
Date: 2006-07-12 12:56:31 CEST

yes, this is the right thing to get going, either " tag "or "branch " they
dont have any difference only for human suitability,


----- Original Message -----
From: "Marc Haisenko" <haisenko@comdasys.com>
To: <users@subversion.tigris.org>
Cc: "Rob Wilkerson" <r.d.wilkerson@gmail.com>
Sent: Wednesday, July 12, 2006 4:18 PM
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"
> 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
> 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
> it'll take a few commits until stuff will work and in the meantime our
> would be broken. By making a "working branch" we can break as much as we
> without interfering with the developers working on trunk. But it's not
> necessarily the best development method for you as well, you need to
> 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
> 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
> conflicts when merging if others changed stuff on trunk while you
> in your branch. Hard to say for me which is the best method for you...
> C'ya,
> Marc
> --
> Marc Haisenko
> Comdasys AG
> Rüdesheimer Straße 7
> D-80686 München
> Tel: +49 (0)89 - 548 43 33 0
> Fax: +49 (0)89 - 548 43 33 29
> e-mail: haisenko@comdasys.com
> http://www.comdasys.com
> ---------------------------------------------------------------------
> 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
Received on Wed Jul 12 12:56:20 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.