Hi Mike,
To solve your problem you may look at the following steps.
1) merge trunk/HEAD into your branch (ie take all changes from trunk
into branch)
2) Checkout trunk HEAD
3) cd to WC of trunk-HEAD
4) svn merge svn://proj1/trunk svn://proj1/branch
5) svn commit
Since you have merged all the latest change in trunk into your branch,
Step 4 should not cause any conflict.
Step 4., basically, does a diff between your trunk version and branch
using the trunk as the "base". This will create a list of changes needed
to make trunk mirror branch/HEAD. When this list is applied to your WC
of trunk-HEAD, trunk-HEAD will mirror branch/HEAD.
You may use --dry-run to test the above.
Thanks
Lakshman
-----Original Message-----
From: Mike Meyer [mailto:mwm-keyword-svn.257b71@mired.org]
Sent: Thursday, 26 July 2007 7:03 AM
To: users@subversion.tigris.org
Subject: Adopting our best practices to svn?
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
=======================================================
The information contained in this email and any files attached may
be confidential information to the intended recipient and may be
the subject of legal professional privilege or public interest immunity.
If you are not the intended recipient, any use, disclosure or copying is
unauthorised.
If you have received this document in error please telephone 1300 307 082
*******************************************************************
This footnote also confirms that this email message has been swept
for the presence of computer viruses.
*******************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 26 04:45:13 2007