Re: Moving a moved file

On Fri, 2003-12-26 at 09:39, Folker Schamel wrote:

> You cannot move a moved file again without an intermediate
> commit of a broken project state, see log below.
> Is there a logical reason for this?

Yes.

> Somehow I would expect that svn commands
> which operate on a wc should be associative
> (-> "move a b; move b c" should be equivalent to "move a c";
> "add a; move a b" should be equivalent "add b" etc.)

See my commentary below. This won't work well. The problem is that the
working copy doesn't have atomic moves. A move is just an 'svn copy;
svn rm'.

> The practical aspect is that if you did a wrong move,
> it is ugly to correct this mistake without checking in
> a broken project state into the repository.

No, just 'svn revert' the move.

> Another practical aspect for example is that you cannot
> move a directory and then afterwards rename files within
> this directory without an intermediate commit.

Yes, this is a known bug, already filed.

Here's the commentary from the bottom of libsvn_wc/copy.c:

/*
  Rabbinic Commentary

  Q: Why can't we 'svn cp' something that we just copied?
      i.e. 'svn cp foo foo2; svn cp foo2 foo3"

  A: It leads to inconsistencies.

      In the example above, foo2 has no associated repository URL,
      because it hasn't been committed yet. But suppose foo3 simply
      inherited foo's URL (i.e. foo3 'pointed' to foo as a copy
      ancestor by virtue of transitivity.)
 
      For one, this is not what the user would expect. That's
      certainly not what the user typed! Second, suppose that the
      user did a commit between the two 'svn cp' commands. Now foo3
      really *would* point to foo2, but without that commit, it
      pointed to foo. Ugly inconsistency, and the user has no idea
      that foo3's ancestor would be different in each case.

      And even if somehow we *could* make foo3 point to foo2 before
      foo2 existed in the repository... what's to prevent a user from
      committing foo3 first? That would break.

*/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 26 16:51:06 2003