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

Re: Strange svn move behaviour

From: Sergio Bossa <sergio.bossa_at_gmail.com>
Date: 2006-05-20 19:50:08 CEST

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:


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,

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
Received on Sat May 20 19:51:14 2006

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.