On 17.06.2005, at 19:26, Jean-Luc Wasmer wrote:
>>> svn merge trunk@HEAD branch1@HEAD branch1
>>
>> I'm not sure I understand what task you're trying to accomplish.
>> Let me see if I understand the scenario.
>>
>> In your repository, you have trunk and branch1. The only
>> difference is that svn:eol-style is different on some files.
>>
>> You have working copies of both trunk and branch1, I'm presuming
>> without any local modifications.
>
> Yes... that is correct.
>
>
>> In your svn merge command, then, you've asked to get the list of
>> changes that occurred between trunk and branch1, and then apply
>> them to your working copy of branch1 -- which doesn't make any
>> sense, because the changes have already been done in your working
>> copy of branch1.
>
> Why have the changes "already been done in [my] working copy of
> branch1"?
>
> The svn:eol-style property was set to native, then branch1 was
> created, then the property was changed to LF in trunk.... now I
> want to merge that modification in branch1. How am I supposed to do
> the merge?
Ok, now I better understand what you're trying to do. My example did
not match with yours. Let me start again:
At revision 10, the svn:eol-style property is "native" in trunk.
At revision 20, branch1 is created from trunk. svn:eol-style is still
"native" in both.
At revision 30, svn:eol-style is changed to "LF" in trunk, and is
still "native" in branch1.
Now you want to bring that svn:eol-style change from trunk revision
30 into branch1 so that svn:eol-style is also "LF" there.
The meaning of svn merge X@P Y@Q Z is as follows: Give me a list of
changes that will convert X at revision P into Y at revision Q. Now
perform that list of changes on Z.
When you wrote svn merge trunk@HEAD branch1@HEAD branch1, therefore,
you requested a list of changes that convert trunk@HEAD into
branch1@HEAD, and then apply them to a working copy of branch1. The
list of changes from trunk@HEAD to branch1@HEAD would be to reverse
your svn:eol-style change: to change it from "LF" back to "native".
(The diff that is produced would also undo any other changes that had
been made on trunk but not on branch1 in revisions 21 to 29.) And
applying this diff to a working copy of branch1 will have no useful
effect, since the svn:eol-style is still "native" there to begin
with. In fact, if there are code changes, not just property changes,
it's likely you will encounter conflicts as well, because the merge
does not make sense.
Before going on, I want to point out something, but I'm not sure what
kind of branch your branch1 is. Is it a feature branch or a release
branch? I've so far only used release branches, so that's what I'll
talk about. If you're using branch1 as a feature branch, then some of
the things I say now do not apply to you (and other things that I am
not saying do apply).
Usually when you backport features from trunk to a release branch,
you won't want to merge everything that occurred on trunk. It would
defeat the purpose of having a separate branch to suddenly make it
the same as trunk again. Rather, you're likely to want to bring one
specific feature or bugfix back to the prior release. In this case,
you want to bring back the change made in trunk in revision 30.
The merge syntax I always follow is svn merge -r P:Q X Z, which
means: Give me a list of changes that will convert X at revision P
into X at revision Q and perform those changes on Z. So, to do what
you want using this syntax, you'd say svn merge -r 29:30 url://to/
trunk path/to/wc/of/branch1. Then you inspect the changes and when
done, commit them.
I believe you can also do it with the syntax you used, as in svn
merge trunk@29 trunk@30 branch1, but I'm not entirely sure, and as
you see you have to type trunk twice, so I prefer the other syntax
where that's not necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jun 18 01:22:46 2005