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..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 17 09:52:17 2006