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...
cheers
dim
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