On Jan 23, 2005, at 6:19 PM, matthew ford wrote:
>
> I tried your suggestion of --ignore-ancestry and swapping the order of
> the
> urls (why this order??)
Because I thought you wanted to generate a patch which showed the
difference between the trunk and the branch. That is, I thought the
branch was equal to the trunk, but had some extra changes. If you
'diff' trunk to branch (in that order), then you'll see only those
extra changes, right?
If the branch is *not* just the trunk code plus some changes, then I
don't understand the relationship between the two trees, and we'll have
to start over. We need to lay a groundwork here that we both
understand.
>
> 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.
Isn't that what you want? If not, then start over and explain what you
want to accomplish. Be specific: don't say, "I want to merge the
branch to the trunk", because that can mean different things. Tell me
how the trunk and branch are related, code-wise, and tell me exactly
which changes you want to isolate and apply, and where you want them
applied.
Somehow, I think we're operating on different definitons of 'merge'.
The term is really a misnomer here. It does *not* mean: "blend two
trees together". 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.
> I expected to get a conflict on line
> - *@author Dr. M.P. Ford make some changes here
> + *@author Dr. M.P. Ford make some different changes here
>
I don't know the specifics of your code, so I can't comment here or be
helpful.
>
> Next I tried your "normal" method of branching from the trunk and then
> making changes in the branch and
> trunk and trying to merge (I did not try merging to un-committed
> changes
> which is what I would expect
> to be able to do)
>
> svn copy -m "branch1" svn://localhost/svnRepos/trunk
> svn://localhost/svnRepos/branches/1
> Committed revision 11
Ok, that looks fine. The branch starts out as a copy of trunk at r11.
>
> made changes to b1 and trunk
> added file to b1 modified existing file committed
> added file to trunk modified existing file, deleted a file (the only
> file in
> a sub-dir, did not delete the sub-dir) committed
>
> svn diff svn://localhost/svnRepos/trunk
> svn://localhost/svnRepos/branches/1
>> diff.txt
>
> svn diff --notice-ancestry svn://localhost/svnRepos/trunk
> svn://localhost/svnRepos/branches/1 >diffna.txt
>
> diff results are exactly the same ?? (see attachements)
>
> svn merge svn://localhost/svnRepos/trunk
> svn://localhost/svnRepos/branches/1
> gave the error output
Here's where you're getting confused. What do you want to accomplish?
Do you want to replicate your branch changes on the trunk?
If so, you would compare the beginning of the branch with the end of
the branch, which chapter 4 of the book explains many times:
svn merge -r11:HEAD svn://localhost/svnRepos/branches/1
That would produce a patch that describes *just* the changes made on
the branch, and then the patch would be applied to your working copy.
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:
http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.1
>
> 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". Thousands of people are happily using Subversion and
performing merges. I suspect you have a fundamental misconception
about what "merging" is actually supposed to do, and therefore are
running in circles. I can assure you, the system works quite well. If
you want, I can have *my* boss come and testify to that. :-)
>
> As for the Documenation
>
> Basic command doc says
> "svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
> In the first form, the source URLs are specified at revisions N and M.
> These
> are the two sources to be compared.
> The revisions default to HEAD if omitted."
>
> There is no indication of what the order url1 url2 means in relation to
> anything else so how do you know to use
> svn merge --ignore-ancestry svn://localhost/svnRepos/trunk
> svn://localhost/svnRepos/branch
> instaead of
> svn merge --ignore-ancestry svn://localhost/svnRepos/branch
> svn://localhost/svnRepos/trunk
>
> Note that the second order is consistent with the copy command from ->
> to
> there does not seem to be any logic in the first order
> As far as I can see there are no examples in the text cover this
> situation
> (no examaple for svn merge --ignore-ancestry)
(--ignore-ancestry is most definitely described in chapter 4, look
again.)
Here's the misconception. The merge command does not work like
svn merge SOURCE DEST
It's *not* a copy command. It's a *diff* command. Think of it as
svn diff LEFT-TREE RIGHT-TREE
svn merge LEFT-TREE RIGHT-TREE
Surely you understand how diffs work; the left and right sides of a
diff aren't arbitrary at all. The left side is what you start with,
the right side is what you want to end up with. The result is a patch
that describes a specific set of changes: specifically the changes
need to convert LEFT-TREE into RIGHT-TREE.
The only confusing here is the name 'merge': a lot of folks think it
has the copy semantic. A better name would have been 'svn
diff-and-apply".
CVS has the same "merging" model. Suppose somebody fixes a bug in
foo.c on a branch, and you've been asked to "merge" the bugfix to the
mainline. You run 'cvs log', and discover that the bugfix happened in
version 1.8.7.5 of foo.c. To replicate the change, you checkout a
working copy of the mainline, then run
cvs up -j 1.8.7.4 -j 1.8.75 foo.c
This generates a diff between the two versions of foo.c on the branch,
and applies that diff to the local foo.c. Commit, and you're done.
Subversion "merges", operate the same way, only you're comparing whole
trees, rather than single files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 24 03:03:57 2005