[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: <brane_at_xbc.nu>
Date: 2002-09-12 08:02:43 CEST

Quoting Karl Fogel <kfogel@newton.ch.collab.net>:

> There is a "back story" to why rename is implemented as delete+copy
> instead of as a single primitive. It's the scenario where someone
> updates a tree in such a way as to receive only one side of a rename
> event.
>
> For example, Joe does
>
> $ svn rename foo/blah.c bar/blah.c
>
> Then, Veronica does
>
> $ cd foo # (or bar)
> $ svn update
>
> When Veronica updates, she should experience the delete (or copy) that
> occurred in the tree she's updating, yet *not* experience the
> corresponding other event, since that occurred in a place she's not
> updating.
>
> I'm not sure how this affects the discussion. Perhaps we just weren't
> imaginative enough when we were implementing rename, and it's actually
> possible to have atomic renames and also have Veronica's update work
> correctly. I just wanted to explain the back story, and make sure
> that people keep the scenario in mind when they're thinking about this
> problem.

This is a good point. Luckily, if (when!) we do rename correctly, it reduces to
two directory changes (possibly on the same directory, of course); so, if your
working copy only has one of those directories, you'll see only one directory
change on update -- which is exactly right.

The bigger problem is this:

    $ cd wc; ls -F
    foo/ bar/
    $ svn mv foo/qux bar/qux
    $ svn st
    D + foo/qux # The '+' here is "delete for rename"
    A + bar/qux
    $ cd foo
    $ svn ci -m 'Committing half a rename?'

(Note, the status output is just an example, I'm sure we can do better.)

We have to either forbid this scenario (unrealistic), or force the commit of
bar/qux even if the commit is in foo/, and that's a non-trivial change in WC
management. A revert must also magically affect the other half of the rename.

I think the right approach would be to do the server- (and FS-) side changes
first, and hook the new rename into "svn mv URL URL", and only tackle the WC
side once that's done.

Good job we don't allow repo<->WC renames. Nor should we.

    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 08:03:19 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.