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. Making rename be two
operations solved this problem.
Let's not have the WC library committing targets that the user didn't
ask to be committed, that'll be scary for users.
> $ 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 if the user doesn't name bar/qux, then we must respect that.
We should just forbid the commit, but tell the user to pass --force if
they really want to do it (while warning them that this will break the
atomic rename semantics and degrade to simple delete+copy). Of
course, when all of the rename is inside one directory, this won't be
an issue -- but we can handle the case where it's not inside one
directory, too.
None of this requires major changes in libsvn_wc, fortunately. We
just
1) Add some metadata to entries, so that an `schedule=add' or
`schedule=delete' entry can also have a `renamed-from' or
`renamed-to' attribute, giving the URL of the companion item.
2) make harvest_committables notice all items that are part of a
rename, and check that the companion item is also part of that
commit.
Etc, etc.
> 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.
+1, sounds like a good strategy!
> 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. :-)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 12 19:04:57 2002