Re: Unusual behaviour of "svn mv" on directories

On Wed, 2004-02-18 at 10:16, Andy Parkins wrote:

> Compare:
> $ svn mkdir A; svn commit -m ""

Your working copy is still at local rev 0, and A is at local rev 1.

> $ svn mv A B; svn commit -m ""

This creates revision 2. After the commit, B is at local rev 2. The
reason you were allowed to remove A is because at the time of the
commit, it was at local rev 1, which was equal to HEAD.

> with:
> $ svn mkdir A; svn commit -m ""

Again, A is now at local rev 1.

> $ touch A/versionedfile; svn add A/versionedfile; svn commit -m ""

And now you've created revision 2. But in your working copy, A is still
at local rev 1, and versionedfile is at local rev 2.

> $ svn mv A B; svn commit -m ""

This will fail, because you're trying to delete A, and your local rev of
A is no longer equal to HEAD.

> There is no difference between the two "svn status" outputs.

Yes there is, run 'svn st -v'. Look at the local revnums. :-)

> My bug report/feature request is therefore: whatever "svn update" is doing
> (which in this case is not its stated function of bringing the local copy up
> to date with the repository); can "svn mv"/"svn rm" not do that as well?

No, because after a commit completes, svn only bumps the local revisions
of things that actually got committed. In your second case, only
'versionedfile' gets bumped to local rev 2, not its parent directory.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 18 17:43:56 2004