Yes the last one was a real mess. Try this one.
Hi again Ben,
I really appreciate your assistance. It is what keeps me going.
I have never used diff, but have quite happly used CVS merge and it worked
as ( I ) expected.
This is what I would like 'merge' to do for me (assuming the common case of
a common ancester)
i) If the file is in the branch:HEAD and was not in the trunk at the time
the branch was made add it to the trunk:WC if it does not exist.
If it exists in trunk:WC merge differences/conflicts line by line.
ii) If the file is in the branch:HEAD and WAS in the trunk at the time the
branch but has since been deleted in the trunk:WC then add and mark as
conflict.
iii) If the file is deleted in the branch:HEAD and is still in the trunk:WC
then mark as conflict.
iv) If the files exist in both branch:HEAD and trunk:WC merge changes and
mark lines that conflict.
How can I do this using subverion?
Tried to start with
svn diff svn://localhost/svnRepos/trunk
svn://localhost/svnRepos/branches/1
but then was stuck as I don't have a patch command on my machine and
subversion does not supply one.
If you can advise on how to get this result it would be greatly appreciated.
matthew
=============================================
The following comments deal with you the question you raised in your email
I thought my second example was quite detailed, basically the branch and
trunk started out the same.
some changes were made to the branch and someone else made changes to the
trunk.
Now I want to 'merge' the changes in my branch back into the trunk.
>>
>> svn merge --ignore-ancestry svn://localhost/svnRepos/trunk
>> svn://localhost/svnRepos/branch
>> This command seems to copy branch to trunk Not what I expected.
>>
>Like I said, it compares the trunk and branch. If the branch is just
>"trunk plus some changes", then the comparison generates a patch which
>only describes the extra changes. If you run the above command in a
>trunk working copy, the branch changes will be applied.
What I have is branch == trunk plus some changes and latest trunk = trunk
plus some changes
Cannot seem to get a conflict on the points where the changes intersect.
In the case above there also is no common ancester between
trunk and branch, but you should be able to handle that?
>What the command really does is "compare two trees,
>generate a patch, and apply the patch to a working copy." It's a way
>of replicating changes from one place to another. But it's up to you
>to supply arguments which generate the correct patch. And it's not
>difficult to figure out.
Why do I need to figure this out?
If there is a common ancester why cann't subversion figure it out for
itself.
If there is no common ancester then that should be a unique case which
subversion can recognise.
>You definitely would *not* want the merge command to compare the trunk
>and branch together: that's the classic newbie mistake. See the four
>pargraphs here in the book:
Well actually I do. To do this my hand I would use BeyondCompare to compare
the trunk to the branch and move the changes from the branch to the trunk.
I had another look at the docs and comments like
"Again, notice that the commit log message very specifically mentions
the range of changes that was merged into the trunk. Always remember to do
this, because it's critical information you'll need later on. "
filled me with dread. I think subversion's merge needs to be made smarter.
I don't really want to have to keep track of my revision history.
I expect subversion to do that for me.
That's why I am using subversion. (Please take this as a constructive
criticism)
>>
>> P.S. I just had a call from my boss who rang to ask how to do a merge.
>> He cannot get it working either.
>I'm sorry you're frustrated, but making pronouncements that the
>software and docs are bad is not a way to make friends, nor are
>comments like the one above. This isn't a battle, there's no "us"
>versus "you all".
In spite of your best efforts to assist me, (which I really appreciate)
I have been battling with subversion merger for the last
two days.
As I said befor the 'User is always right' There are at least
two users out here who don't think "the subversion" way. And since my
background is different from my boss', I suppect we are not the only
ones. Your comment about "the classic newbie mistake" also suggests
that we are not alone.
How can I encourage the subversion developers to modify the way merge
operates or is documented so that newbie can just use
it stright out of the box?
OK lets try again as before both branch and trunk have been change after
the branch was created.
C:\temp\svnTrunk>svn merge -r 13:HEAD
svn://localhost/svnRepos/branches/1
C oldFileInTrunk.txt
A newInBranch.txt
This almost worked. Now I get a conflict on the change
<<<<<<< .working
This file existed in trunk prior to branch b1 has been modified in trunk
=======
This file existed in trunk prior to branch b1 has been modified in b1
>>>>>>> .merge-right.r16
but there is no report to tell me that the trunk has deleted a file that is
in the branch and which the branch may depend on.
I can see why this is so from the command above, as the
command makes no reference to my current trunk. This is probabily the main
source of the problems I have been having. I want merge to merge the
differences between the current branch and the current trunk.
I don't what to have to care what merges I have preformed
in the past or when the branch was taken from the trunk.
(see statement of need at the top of this email.)
(Also
revert on the merged trunk did not remove the new file added from branch
A newInBranch.txt
so in this regard revert did not revert.)
matthew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 24 06:16:18 2005