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
__________________________________________________________________________
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