[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Unusual behaviour of "svn mv" on directories

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-02-18 17:39:03 CET

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.