> From: Karl Fogel [mailto:firstname.lastname@example.org]
> email@example.com 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.
Well, of course, that makes perfect sense.
> > $ 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
> > 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
> in WC
> > management. A revert must also magically affect the other half of
> 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.
Blech. I don't like the idea of breaking up the conceptual move
Please have it be all or nothing. Delete+copy just causes problems the
user won't fully understand/grasp if you let them break the rename into
two separate chunks. All of these reasons are what we've been talking
about recently. Don't let the user screw themselves over.
> None of this requires major changes in libsvn_wc, fortunately. We
> 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
3) If companion items aren't part of the commit, then issue error, and
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Sep 12 19:38:48 2002