Re: Strange svn move behaviour

On 5/20/06, Andreas Pakulat <apaku@gmx.de> wrote:

> No, the difference is that svn mv tells subversion to move the history
> of that file, while when doing a svn delete and an svn add afterwards
> you get 2 different files in the repository and nobody will know that
> test_file_rn is the same as test_file only with a different name.

Yes, you are right, I forgot.
Thank you for specifying this.

> > The update seems to have no effect, but then the problem doesn't
> > appear ... why do we need to make an update?
>
> I guess this has to do with subversions global version numbers. Say you
> have a working copy in directory wc and a file foobar in it. When you do
> a svn commit foobar, foobar in your working copy is at the "newest"
> revision, however . (the working copy directory) is still on the old
> revision, you can easily check with svn info. You need to update ., even
> though this will just update svn's 'metadata'.

Ok, I think this SVN behaviour is a bit unclear, but now I understand.
I had already solved the problem deleting the following wrong entry
form the "entries" file:

<entry
   name="test_file_2_rn"
   copied="true"
   kind="file"
   schedule="delete"
   revision="19"/>

This was the entry related to the non-existent file, deleted weeks ago.
Could this cause some problem in my repository?
May I have lose something?

Thank you for your explanation,
Regards,

Sergio B.

-- 
Sergio Bossa
Developer, software designer, blogger and Open Source believer.
Blogging on: http://sbtourist.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org