Needed for jackrabbit 2 - since its no longer part of jackrabbit,
but I need a distinct key type so node referecnes can go in the same
map/database as node state.

This passes the (limited) unit tests against jackrabbit2. This version is not compatible with jackrabbit1, either in terms of compilation, or on disk format of repositories. I'm not sure thats going to be possible in future either. Hence I'm creating a branch for Jackrabbit 2 support.

This seems mostly to be about eliminating
compilation warnings. I need to merge...

Yet another variation on the persistence manager. This is much simpler
than the others - using jackrabbit libraries more, because most
optimisations are handled by the bundle persistence manager by
default.

Its hard to say if it performs well, and I haven't tested it with a
datastore yet.

Add the ability to run tools which don't modify the database in
read only mode, hence this gives us a hot backup.

Dealt with a bug that causes database values to be padded with zeros
to block boundaries. This substantially increases the size of
the database.

This is also a merge of some refactoring from my previous commit
done on another copy of the code.

Missing from previous commit - skeleton of a data store

Theres some refactoring here: moving the key generators into
separate top level classes. Support for DataStore is added to
the persistence manager, and the blob store gets just enough
file system support to work as a resource based blob store.
All this aims to reduce memory requirements in Jackrabbit as
a whole.

This is a fast checksum of Paul Crowleys devising. I've added it
because SHA1DIgest was slowing things down significantly. I'll
have to get him to add some notes about it somewhen.

Working blob de-duplication.

Detect duplicate blobs. Count references to them, and delete them
when they are no longer referenced.

That solves the dynamic dispatch problem. I don't understand why the previous versiondidn't work, but this one does.

Re-applying an optimisation that avoids large byte array allocations and copies in blobs.

I was actually quite wrong to think the stringKey order was the same as the binaryKey order - the numbers assigned to strings have a completely different ordering to the strings themselves. Its not very hard to use the actual order.

Don't delete the blobs of the new value after you have just written them! Add and modify no longer have enough in common to share a method. Separated them.

Optimisation which sorts changes by their key before submitting them to BDB.
BDB may do a fairly good job of this already, so its just an experiment.

This arranges for no-longer used blobs to be deleted. It also replaces the export with one that can cope with the internal blob store or an external one - either way, the blobs are included in the export file. The import only works if the target repository uses internal blobs. I've fixed some warnings that resulted from BDB collections interface now being parameterised.

Blobs with locality and binary keys now works. Haven't tested
String based keys yet. Blob locality seems to improve write
performance by 10-20% in my ad hoc test of importing the
encyclopedia britanica.

Fixed various issues with the binary binding. This worked a little while ago when I had a separate map for blobs. Then I realised that meant I'd lost locality for blobs, so I merged them back into items. I don't know if that works yet.

This is really just an in progress dump: I have a binary key binding that might work, as long as you don't use blobs

Use tar instead of zip - writig tar files doesn't use memory,
while writing zip files keeps a table of contents in memory,
which is bad, under the circumstances.

Use tar instead of zip: zip keeps the table of contents in memory,
which means the export could run out of memory.

Tool to dump database statistics

Refactored so I can add a binary key generator, for more compact
keys. tests run but thats not saying all that much.

This is a big commit - It should have been done on several
branches:

1) I've started work on a FileSystem implementation, which
invovled fgactoring out some common code.
2) This was partly superceded by adding blob support
directly to the persistentence manager
3) I've added some tools to import/export the repository into
a zip file. This is a work in progress: its not possible
to unzip the zip file.

Added tag 1.2.1 for changeset 3ddab77d0b29

Refactor out common functionality that I can use in an implementation
of FileSystem later

I though I'd removed these already, but then I updated and
got them again. This is all in lshift-jcr.

Use internal lshift jackrabbit repository temporarily

Some reformatting, and removed some comments that are now out of date

Move the examples to the right place

These are part of the import tool - not the persistence manager

This is a clone of the jcr project, pruned down just to contain
the bdb persistence manager. It may still have some unneccessary
dependencies.

Documentation, examples

This changes the way me manage an envronment. Clients name themselves,
and the environment closes when all the clients release it. This seems
delicate, to say the least, so there's also a servlet context listener
you can use to make sure all environments are closed when the context
is shut down.

Remove eclipse config and maven target

update tags

bug none: use only one database for everything

bug none: use dynamic dispatch to clean things up a bit. Add some documentation. Time to release a new version.

bug none: this is back to the point where it seems to work reliably.
There are several changes:
- uses an external block store
- uses jackrabbit's own build in serializations
- do everything in a transaction and use serializable isolation

Its the last one that makes everything work reliably.

bug none: don't use openDatabase() inside a transaction - writes to the database after the transaction is committed may be lost. Also checkpoint the environment when a persistence manager is closed - just to make sure its easy to start up again afterwards.

bug none: I mistakenly published multiple versions under the same version id. This should end the confusion

bug none: some refactoring of the import and export tools. Its safer to test things with export. This doesn't work, but probably only because I don't have a complete enough classpath.

bug none: cosmetic and documentation changes. Some warnings are suppressed.

bug none: This has various generally useful tools for use with jackrabbit. The only think I really want right now is the jackrabbit.BDBPersistenceManager which I'm considering using on Sodexho. I've tested it as working with Magnolia.