2009/3/23 Robert Roessler <robertr_at_rftp.com>:
> Stefan Küng wrote:
>> Robert Roessler wrote:
>>> Stefan Küng wrote:
>>>> Robert Roessler wrote:
>>>>
>>>>>> Seems you're using the BDB repository format. That isn't supported
>>>>>> anymore in TSVN 1.6 (see the release notes).
>>>>>> You have to convert your repository to FSFS format if you want to keep
>>>>>> accessing it via file:///
>>>>> But no, I have *never* [knowingly] set up a repo to use BDB - even my
>>>>> very first one, which this isn't... if it helps, the .svn file tree in
>>>>> the repo and WC appears substantially the same as all the other working
>>>>> repos.
>>>>>
>>>>> If I need one, is there some definitive test for examining the file
>>>>> trees of a repo or WC to determine its "format"?
>>>>>
>>>> In the db folder inside the repository is a file named fs-type. Open it
>>>> with a text editor. It contains either "FSFS" or "BDB".
>>>>
>>>> If you're using FSFS, try running 'svnadmin recover' on it.
>>>
>>> As expected (by me, anyway ;) ), my afflicted repo is indeed FSFS...
>>> which makes sense, since I create all of them using the same procedure
>>> and folder-tree template.
>>>
>>> In any case, svnadmin recover gives the same error as the repo browser:
>>>
>>> "Can't open file '...\db\min-unpacked-rev': The system cannot find the
>>> file specified"
>>>
>>> However, I notice that none of my other repos contains such a file -
>>> whatever that means.
>>>
>>> BUT, this repo is the only one that contains a "rep-cache.db" file.
>>>
>>> Finally, I note that 4 out of my 6 repos contain a ".../db/format" file
>>> that looks like this:
>>>
>>> 3
>>> layout linear
>>>
>>> While 2 of 6 repos (1 working fine, and this messed-up one) have
>>>
>>> 4
>>> layout sharded 1000
>>>
>>> Is there anything else I can check? Any theories as to how this
>>> happened? Could it have been a failed attempt at auto-updating the repo
>>> format with a new client version?
>>
>> If 'svnadmin recover' also throws an error, that's not a good sign. You
>> might have to get the repo back from a backup.
>> Try 'svnadmin dump /path/to/repo> dump.dmp'
>> and then load it into a new repo.
>>
>> If that doesn't work either, you have to use a backup (or as on the
>> Subversion list for help).
>
> Since any function that needs to use/contact the repo (rather than just
> using the WC) asks for this "min-unpacked-rev" file, you can guess how
> well the "dump" operation went...
>
> But what I really don't get is that of ALL my repos, the only one that
> even HAS this "min-unpacked-rev" file is my newly created and
> "re-imported" version of the broken one.
>
> The fact that this problem repo is 1 of 2 repos that are using this
> newer internal FSFS layout still leaves me worried about WHY this
> corruption (or whatever) occurred... but it almost certainly has to do
> with the SVN libs and not TSVN (of course).
I think you will have to take this one to the subversion users list.
If the repo will zip to a relatively small file that may help with
diagnostics.
IIUC repositories never auto-upgrade, so it is more likely that you
created this repo sometime after a format change was introduced to
FSFS. Sharding became the default in svn 1.5 which has been out for
quite some time, so it is not surprising that some of your repos have
this.
Also, I think the min-unpacked-rev file is new to 1.6 and has to do
with shard packing. But that should only happen when you run svnadmin
pack.
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1399660
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-24 10:06:44 CET