Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-384

db3 broken on Win32



    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Won't Fix
    • all
    • 0.14.0
    • src
    • None
    • Windows 98


      I have three boxes running the latest build of Subversion under
      Win98.  Compilation all happened without a hitch.  I have svn.exe and
      svnadmin.exe binaries built, as well as all the Berkeley db_xxx.exe
      tools.  From the looks of it, I should have a working local
      After a successful run of `svnadmin create repos' (in c:\), I have the
          .              <DIR>        05-10-01 10:19a .
          ..             <DIR>        05-10-01 10:19a ..
          LOG~1    000        67,994  05-10-01 10:19a log.0000000001
          NODES               16,384  05-10-01 10:19a nodes
          REVISI~1            16,384  05-10-01 10:19a revisions
          STRINGS             16,384  05-10-01 10:19a strings
          TRANSA~1            16,384  05-10-01 10:19a transactions
          __DB     001             8  05-10-01 10:19a __db.001
          __DB     002             0  05-10-01 10:19a __db.002
          __DB     003             0  05-10-01 10:19a __db.003
          __DB     004             0  05-10-01 10:19a __db.004
          __DB     005             0  05-10-01 10:19a __db.005
                  10 file(s)        133,538 bytes
                   2 dir(s)       33,768.03 MB free
      Now, I'm not entirely certain, but the sizes of those index files
      look kinda scary.  I can use db_dump to see all the tables themselves
      with no complaints (nodes, revisions, transactions, strings), but any
      time I programmatically to try to access the database, an error
      occurs.  For example:
          C:\repos>svnadmin lsrevs .
          svn_error: #21055   Berkeley DB error while opening environment
          for filesystem .:
          Resource temporarily unavailable
      Now, I traced into the BDB code far enough to find where it fails.
      BDB is trying to open the file "repos\__db.001", and is doing all
      kinds of fun memory-mapping stuff, but once it's done so, it appears
      to be reading some "region" information (a REGENV structure) from the
      file, and when it can't find its magic thumbprint (DB_REGION_MAGIC),
      it whines and quits.
      So I looked at output of the same command when run in Linux:
          -rw-r--r--    1 cmpilato users        8192 May 10 10:26 __db.001
          -rw-r--r--    1 cmpilato users      270336 May 10 10:26 __db.002
          -rw-r--r--    1 cmpilato users       98304 May 10 10:26 __db.003
          -rw-r--r--    1 cmpilato users      319488 May 10 10:26 __db.004
          -rw-r--r--    1 cmpilato users        8192 May 10 10:26 __db.005
          -rw-r--r--    1 cmpilato users       35226 May 10 10:26 log.0000000001
          -rw-r--r--    1 cmpilato users        8192 May 10 10:26 nodes
          -rw-r--r--    1 cmpilato users        8192 May 10 10:26 revisions
          -rw-r--r--    1 cmpilato users        8192 May 10 10:26 strings
          -rw-r--r--    1 cmpilato users        8192 May 10 10:26 transactions
      I took a look at the binary goo inside the Unix-created repository's
      __db.001 file, and at the top, I saw actual header information,
      including Berkeley's magic number.  In fact, I found it really odd
      that the index files under Windows where zero-length (except that one
      odd 8-byte one), but under Unix, everything had at least 8k.
      I've run into problems with APR in the past where they haven't kept
      their MS API docs up-to-date enough to realize that sometimes Win98
      doesn't behave exactly like Win95.  I don't know if this is a similar
      issue for Berkeley.  What I do know is that this happens on all three
      of my Win98 boxen, and that it kinda puts a dent in my plans to make
      sure Subversion is just as great under Windows as it is under Unix! :-)




            Unassigned Unassigned
            cmpilato C. Michael Pilato
            0 Vote for this issue
            0 Start watching this issue