Sander Striker wrote:
>>From: Branko Cibej [mailto:brane@xbc.nu]
>>Sent: Friday, April 11, 2003 8:47 AM
>>
>>
>
>
>
>>Jack Repenning wrote:
>>
>>
>>
>>>This all depends on having svn:merged props to record the merge history.
>>>But is there always somewhere to park that property when you need it?
>>>Something here I'm not quite following, probably because I haven't fully
>>>grokked a more basic question ... So I'll ask that one:
>>>
>>>If you merge a URL into your WC, some files will change and others will
>>>not. Can you attach a new svn:merged to all the files in the WC, even
>>>the unchanged ones, without losing any existing svn:merged?
>>>
>>>
>>If the file didn't change, you don't have to record any merge history.
>>You can, of course, and it doesn't hurt, but it's not necessary to the
>>proposed algorithm.
>>
>>
>
>Right. For consistency I was thinking to always record the merge in
>svn:merged-from, even on unchanged files. Then again, we do not
>need it and it is unrequired overhead...
>
>There is a use case for recording svn:merged-from for files that haven't
>changed though. We might want to tell merge we want to sync up to
>branch@Y (MRMR = branch@X), but to ignore all changes. This way you
>can avoid certain changes on 'branch', since next merge will be from
>branch@Y to branch@HEAD, effectively bypassing the changes in
>branch@X:Y. And yes, we do need an extra switch to pass to svn merge
>for that. Ofcourse you can argue that this use case does have changed
>files, namely on branch (MRMR:L), instead of the working copy (M:WC).
>
>
Yup. That's what ClearCase does with its option to "just draw a merge
arrow, don't peform a merge".
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 09:15:45 2003