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

RE: 2-way merging - bad?

From: Shawn Oster <SOster_at_colorflex.com>
Date: 2005-06-22 20:02:17 CEST


> -----Original Message-----
> From: John Browne [mailto:jkbrowne@gmail.com]
> Sent: Wednesday, June 22, 2005 10:33 AM
> To: Joshua Varner
> Cc: subversion
> Subject: Re: 2-way merging - bad?
> Thanks for the information. The thread in the third link
> above brings me to another question. It mentions that the
> trunk is typically used for enhancements and bugfixes, then
> changes ported to a specific branch for releases. I always
> thought it was the other way around.....maybe a branch such
> as "/branches/development" that was ported back into the
> trunk, then the trunk is tagged and releases are created from
> the trunk.
> Or do I have it backwards? :)

Not sure if it's backwards or not but here is what I do, though I start
doing a little branch dance around release time. Goes something like

1. slog away on trunk towards 1.0
2. release 1.0, create /tags/1.0
3. create /branches/1.0
4. work towards 2.0 on trunk
5. user finds bug in 1.0, can't wait until our next release cycle so fix
it in /branches/1.0
6. after bug is fixed, create another tag, /tags/1.0.1

In that context I strictly use the branch for minor bugfixes. I usually
don't even do a merge from branch to trunk on the bugfix because it's
possible the trunk code has been refactored. Instead I just fix the bug
in two places, if it even exists in the trunk at all.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 22 20:02:30 2005

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.