> I apologize if I'm fostering ill will here.
I think we're in agreement -- and no offense taken or meant!
> At the same time,
> though, I want to advocate (in a minor way) for less brittleness in
> BDB. I want it to be possible to access a BDB database from a Red Hat
> Linux process, reboot the machine to Windows, and access the very same
> database from a windows process.
That is possible now, as far as I know (although I must admit
I've never tried it). You'll have to run recovery, that is,
the database environment files aren't portable between the two
systems, but the actual databases are.
Log files aren't yet portable between systems of different
endian-ness (we are working on that problem), but with two
machines of the same endian-ness, I think it will work fine.
> I want it to be possible to use
> different 4.x versions of BDB against the same database.
That is also possible now. The underlying database formats
have not changed in quite a while.
Oh... by "database" you mean what Berkeley DB terms "database
environments" that is, the whole transactional shooting match.
That isn't ever going to be possible. We would have to make the
underlying Berkeley DB shared memory regions portable between
releases, and that's not possible. (Imagine making Subversion's
in-memory data structures portable between releases. That's a
task of equivalent magnitude, and I'm sure you can understand
why we don't want to take that on.)
> I want a
> process to be able to terminate without closing its cursors and not have
> the database slowly leak locks until it requires recovery.
This will be possible in our upcoming 4.4.XX release.
> I want a process to be able to terminate uncleanly without the
> database requiring recovery.
This will be partially possible in our upcoming 4.4.XX release.
As long as the process doesn't terminate while running inside
of Berkeley DB itself, it will be possible to clean-up after an
unclean termination in the 4.4.XX release. If the process dies
inside DB itself, we can't fix things (for example, we'd have
to be able to handle a shared memory linked-list being randomly
corrupted after the failure, and that's a task of an entirely
different magnitude).
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic@sleepycat.com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 13 18:31:02 2004