Re: Problems merging renamed file with contents changes

Karl Fogel wrote:

>brane@xbc.nu writes:
>
>
>>The bigger problem is this:
>>
>>
>
>:-)
>
>I don't see that this is a "bigger" problem -- I think it's
>essentially the same as in updates. The problem with rename is that
>it has two targets, and the committer (or updater) could choose to
>commit (or update) just one of those targets.
>
Oh no, it's quite different duting update. If you don't update both
halves of a rename, that's just another case of your WC not being in
sync and up-to-date. Nothing tragic will happen (except that your code
might not build, but that's to be expected in this a case anywhay).

>Making rename be two operations solved this problem.
>
For the update case, it'll still be two operations (on the WC side, of
course),

>Let's not have the WC library committing targets that the user didn't
>ask to be committed, that'll be scary for users.
>
[etc.]

Hm. Well, yes, I expect that if we can just bail out and identify the
missing half of the commit, that sould be sufficient, yes.

[snip]

>>Good job we don't allow repo<->WC renames. Nor should we.
>>
>>
>
>Hunh.
>
>/me wonders a) why we don't, and b) why we shouldn't. :-)
>
>
Very simple, really: unlike copy, rename implies an immediate change
(and commit) when acting on an URL source, not just target. Allowing
URL<->WC renames would explicitly break atomicity. So it's only right
not to allow that.

-- 
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