Hi Baz,
Thanks for your response. Just one clarification.
========================================================================
Baz wrote
----------
svn merge svn://..../trunk svn://..../branches/project_A
This will provide a list of changes that would undo anything that's
been done on the trunk and *then* apply the changes on the project A
branch. Also unlikely to be what you want.
========================================================================
=
Since I am merging regularly from trunk into project_A, wouldn't
project_A have all changes from trunk ? that being the case wouldn't svn
merge svn://..../trunk svn://..../branches/project_A be only the
enhancement done in project_A. ie the changes I need to apply into
project_B.
If I am incorrect, could you please identify my misunderstanding.
I am base my reasoning on
http://svn.haxx.se/users/archive-2006-01/0149.shtml from Ryan Schmidt.
ie trunk => A
project_A => B
project_B => C
Any help/suggesting is greatly appreciated.
Thanks
Lakshman
-----Original Message-----
From: Baz [mailto:brian.ewins@gmail.com]
Sent: Monday, 8 May 2006 7:49 PM
To: Lakshman Srilakshmanan
Cc: users@subversion.tigris.org
Subject: Re: Merging 2 branches
On 5/8/06, Lakshman Srilakshmanan
<lakshman.srilakshmanan@tradingpost.com.au> wrote:
> svn merge -r 18:655 svn://..../branches/project_A
[snip]
> I have the following structure
>
> /branch/project_A branched from trunk at 17
> /branch/project_B branched from trunk at 49
[snip]
> When I tried to merge project_A (r18:655) into project_B I get an
error
> "skipped bla bla". Investigation revealed that the files skipped were
> deleted in trunk. These changes have obviously been merged into the
> respective branches.
^^ since you say changes have been merged into project A from the
trunk *after* revision 17, you're going to want to know the revision
number where that happened. Have you checked your logs to see when the
trunk changes were applied? BTW, if files *have* been deleted in both
branches, then its not a problem if that change is skipped since the
change was identical.
Replying to your previous options:
svn merge -r 18:655 svn://..../branches/project_A
as I said above, this may be trying to merge too much, because some of
the trunk changes have been applied to *both* branches. However it
should be pretty close to being correct.
svn merge svn://..../branches/project_A svn://..../branches/project_B
this would give you the changes that would take 'project A' and make
it identical to 'project B'. Since you're already in project B this
doesnt make sense.
svn merge svn://..../trunk svn://..../branches/project_A
This will provide a list of changes that would undo anything that's
been done on the trunk and *then* apply the changes on the project A
branch. Also unlikely to be what you want.
Your difficulty here is that changes have been applied to both
branches. If the same change was applied to both branches at, say,
revision 25, you could do this in two merges:
svn merge -r 18:24 svn://..../branches/project_A
svn merge -r 25:HEAD svn://..../branches/project_A
skipping the point where the trunk changes got merged back in. Its
unlikely though that all the changes will all apply cleanly, however
you try this - at some point you're going to have to deal with
conflicts.
The general case, where you apply changes in the project A branch one
revision at a time, is called 'cherry picking'. There are some scripts
people have written to help with this, but I'm not familiar enough
with them to recommend something. It sounds to me like your first
attempt at a merge should have been pretty close to being correct, but
if you are really stuck asking questions about cherry picking may get
you some good advice.
-Baz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 9 03:30:51 2006