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

Adopting our best practices to svn?

From: Mike Meyer <mwm-keyword-svn.257b71_at_mired.org>
Date: 2007-07-25 23:03:22 CEST

I'm trying to adopt our current best practices for dealing with
convergent branches to svn, and having difficulty with one step. I'm
hoping someone here has been through this before, and can provide a
way to deal with things.

When we have a change that's going to result in an unstable tree for
any period of time, we create a branch to work on. We then follow
that sage advice, and "merge early and often", adding changes in the
trunk to our branch on a regular basis. When the change is done, we
merge in any remaining changes from trunk, run our regression tests,
and then we're through. At this point, we want the trunk to become a
copy of the branch.

And that copy is the sticking point. "svn copy" won't work, because
the trunk is already populated. A merge of the work on the branch
isn't right, because that includes changes that have are already in
the trunk. More accurately, modified versions of them, as they may
have been dropped from the branch as irrelevant, or fixed in another
way, etc. We definitely don't want those after the copy back.

Up to now, the solutions we've tried have been:

Don't do incremental merges, and merge from the branch back to the
trunk. Besides violating the principle of always merging into less
stable branches, this makes that final merge a nightmare, and
destabilizes the trunk for longer than we'd like

Delete the trunk, and then do a copy. This does things to the log data
that are unappetizing, to say the least.

Try merging changes on the branch into a copy of the trunk from before
the merge. But then we can't check that back in without merging all
those changes we've already dealt with into our working copy.

Is there a way to do what I'm trying to do? If not, what's the
alternative best practice for dealing with branches? The FAQs and
recommended best practices I found on the web all talk about when to
make them, but not how to merge them back into trunk.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 25 23:04:33 2007

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.