Ben Collins-Sussman <sussman@collab.net> writes:
> On Dec 7, 2004, at 2:47 AM, Niels Skou Olsen wrote:
>
>> Ben Collins-Sussman <sussman@collab.net> writes:
>>
>>> On Dec 4, 2004, at 7:09 AM, trlists@clayst.com wrote:
>>>>
>>>> [merge applies properties in wc]
>>>>
>>>
>>> If you tell 'svn merge' to merge a whole directory, there's no way to
>>> have the command pay attention to some differences and ignore others.
>>> The merge command is really very simple: "compare two trees, and apply
>>> the resulting patch to my working copy". No filters, no fancy
>>> switches, no frills.
>>
>> One could argue that merging in a change to a property that is already
>> set and has a different value is a conflict.
>
> Of course, but only if the existing property value is a 'local edit'.
I may be mis-interpreting the terminology here, but when I see the term
'local edit' I take it to mean a scheduled propchange in the working
copy. I would still argue that it is a conflict even if there are no 'local
edits', because the propchange was comitted independently on branch and
trunk. I guess that is what issue 2035 is about -- hadn't seen that one..
> When that happens, the file is marked in conflict as usual, and a '.prej'
> file is created to describe the conflict, rather than conflict-markers.
> This is how 'svn up' has always behaved, try it.
I have tried it now, and I really like this way of handling it -- great!
>> So it should be subject to conflict resolution as for file content
>> edits. If Subversion just overwrites property values silently we may not
>> notice it and loose data.
>>
>
> Funny you say that... there *is* a bug in 'svn merge' like this:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2035
Best regards,
Niels
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 8 10:29:59 2004