[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problems merging renamed file with contents changes

From: Branko Čibej <brane_at_xbc.nu>
Date: 2002-09-12 21:46:49 CEST

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

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

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.


>>Good job we don't allow repo<->WC renames. Nor should we.
>/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
Received on Thu Sep 12 21:48:07 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.