[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: Ryan Schmidt <subversion-2006q2_at_ryandesign.com>
Date: 2006-05-20 20:13:44 CEST

On May 20, 2006, at 19:50, Sergio Bossa wrote:

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

The confusing fact that Subversion allows mixed-revision working
copies, when they can occur, how to use them, what they're good for
and what to watch out for is described in the book:

http://svnbook.red-bean.com/en/1.2/svn.basic.in-
action.html#svn.basic.in-action.mixedrevs

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

I have no information about the format of any file inside the .svn
directories. Their contents are not meant to be changed by hand. I
imagine that making incorrect changes to files in the .svn
directories and then interacting with the repository could very well
store incorrect data in the repository. I do not know whether the
changes you have made are correct or incorrect. I can only recommend
not editing anything in the .svn directories, as doing so should
never be necessary. If it were necessary, it would represent a bug in
Subversion which should instead be fixed.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 20 20:14:39 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.