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

Re: [BUG ?] strange behavior of 'svn move'

From: Archie Cobbs <archie_at_dellroad.org>
Date: 2004-10-16 00:29:27 CEST

Stefano Spinucci wrote:
> Because a svn move (or rename) is simply a delete and
> a copy, I noticed the 'strangeness' also in the
> following case:
> in the working copy ONE :
> 1) create the dir 'dir1'
> 2) create the file 'file1' inside 'dir1'
> 3) add 'dir1'
> 4) commit
> 5) delete 'file1'
> 6) commit (this point maybe skipped)
> 7) copy 'dir1' in 'dir2'
> 8) commit
> in the working copy TWO :
> 9) update
> and you 'll get :
> * 'dir1', empty
> * 'dir2', with 'file1' inside (remember that 'file1'
> were deleted at the point nr. 5)

I think that if you did an update of 'dir1' before step 7 then
you would get the expected behavior. SVN is copying the revision
corresponding to the checked-out version of 'dir1', which is
apparently not the most recent version (after step 5).

This is a little tricky.. there are some cases like this where
SVN's behavior of taking the revision number from .svn/entries
instead of taking the head revision is surprising.

A similar case I've noticed is when you say "svn log ../foo/bar"
where "../foo/bar" is a working directoy that you haven't updated
for a while, and you don't see any log messages past the revision
in which it was last updated. In this case I would expect SVN to
interpret "../foo/bar" as simply a "shortcut" and really be using
the URL corresponding to "../foo/bar", but that's not what it does..
After all, when would you ever not want to see the most recent
revisions in the log?


Archie Cobbs * CTO, Awarix * http://www.awarix.com

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 16 00:30:33 2004

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

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