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

Re: Adopting our best practices to svn?

From: Dmitri Colebatch <dim_at_colebatch.com>
Date: 2007-07-26 00:04:29 CEST

Hi Mike,

Just a thought, lets suppose you have the following scenario:

1. revision 123
2. create branch
3. many changes to branch, and merges to trunk
4. revision 182

you now want the branch to be a copy of trunk.... could you:

  cd trunk
  svn merge -r 182:123
  svn merge http://svn/repos/foo/trunk@123 http://svn/repos/foo/branch/bar@182 .

I haven't fully thought this through, but the basis of it seems to
worth in my mind...


On 7/26/07, Mike Meyer <mwm-keyword-svn.257b71@mired.org> wrote:
> 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.
> Thanks,
> <mike
> ---------------------------------------------------------------------
> 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 Thu Jul 26 00:03:29 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.