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.
> -----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 this
> > it will go to the entire list.
> > ==================================
> > Thanks, Nick. That makes a lot of sense and is the exact opposite
> > 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
> > 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
> stable branches from it.
> Another is "trunk is stable" which means that development takes places
> 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
> 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
> 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
> > I'm about to face...once I import my current stable version and
> > a branch for that version my trunk will look exactly the same as
> > branch. For the next version, though, the code base will be
> > 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
> > 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
> 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..
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jul 17 09:52:17 2006