Some serious digging and delving identified the problem:
A user did the following command sequence:
svn add Prospectus.tex
svn ci
mv Prospectus.tex prospectus.tex
svn add prospectus.tex
svn ci
Now, because by default HFS does not distinguish between the two
filenames, but svn does, it tried to check out the same file twice,
and write different meta-data files, which apparently it couldn't.
This breaks the working copy where you attempt a checkout or update.
svn cleanup will not fix this!
The solution is that the criminal who actually did the incorrect
rename does a 'svn delete' on one of the two filenames and commits
that change. After that
svn cleanup
svn update
fixes affected working copies. You may need to delete the meta-data,
but at least you get back a working copy.
Jochen
On Dec 10, 2010, at 2:33 PM, Wuttke Jochen David wrote:
> The server and client are running version 1.6.6.
>
> The server is running CentOS, client is Mac with the commandline
> client.
>
> The command was as expected:
> svn checkout https://my_url
>
>
>
> On Dec 10, 2010, at 12:34 PM, Giulio Troccoli wrote:
>
>>>
>>
>>
>> Linedata Limited
>> Registered Office: 85 Gracechurch St., London, EC3V 0AA
>> Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
>>
>> -----Original Message-----
>>
>>
>>> From: Jochen Wuttke [mailto:wuttkej_at_usi.ch]
>>> Sent: 10 December 2010 11:03
>>> To: users_at_subversion.apache.org
>>> Subject: Strange meta-data problem when checking out
>>>
>>> Hi,
>>>
>>> when I try a fresh checkout from a shared repository I get
>>> the following error message:
>>> svn: In directory 'prospectus'
>>> svn: Can't open file
>>> 'prospectus/.svn/tmp/text-base/prospectus.tex.svn-
>>> base': No such file or directory
>>>
>>> A friend also tried a fresh checkout and got the same error.
>>>
>>> I tried 'svnadmin verify' on the repository and it verifies
>>> all revisions. I looked at the files stored in that offending
>>> directory via svnlook to see if someone tried to add the
>>> meta-data from .svn to the repository somehow, but did not
>>> see anything that shouldn't be there (i.e. only the files we
>>> need, no meta-data).
>>>
>>> I tried google for some hints on what causes this problem and
>>> how to fix it, but didn't find much that is promising. If at
>>> all possible I'd like to avoid restoring a backup, and since
>>> all revisions verify, I wouldn't now which revisions to dump
>>> to repair the problem.
>>>
>>> Any ideas?
>>
>> What is the exact command? What is the SVN version? OS?
>
Received on 2010-12-10 15:08:27 CET