[elephant-devel] Version 0.5.0 vs. 0.6.0

[Ian Eslick]

Trac and SVN
-------------------

I'm in the middle of a huge set of changes - I'm debugging the last  
set of BDB issues and planned to switch to SVN once that was done  
rather than pollute HEAD with a non-working version.  Checkins to  
HEAD at this point would probably create a complex set of conflicts.   
Normally I would do this scope of change incrementally, but the  
supporting changes touched quite a few files and I fixed a set of  
long-outstanding problems along the way.

Until recently Robert and I were the only ones willing to do coding  
and development work so working in my local copy for awhile wasn't an  
issue (as Robert is busy with other things).  Moving to SVN and Trac  
should help us include more people in the design, bug-fix and feature  
enhancement process now that the user and potential developer  
community seems to be growing.

My next task is to put all the current TODO items with an expanded  
description into Trac so everyone can comment, etc.


Upgrading and Migration
---------------------------------

I wouldn't bother with 0.5.0 upgrading - I'm happy to walk the 1 or 2  
users through the process of taking existing data up to 0.6.0 if they  
need it.

What would be nice, and be a good tool in general, is a general way  
of walking the database and dumping it to a clean external format  
(xml with lisp-readable primitives?) and a way to reload that  
external format.  That's a good way of backing up data in a format  
that is highly transparent and independent of any binary  
serialization strategy.  This could easily be based on the migration  
code in the current 0.6.0 or HEAD repository and would be orthogonal  
to the changes I'm making.

Robert and I would like to minimize external library dependencies, so  
perhaps an optional xml dump utility using a 3rd party library could  
be provided as an asdf-loadable option?

Additionally, there are a few migration issues (like following  
persistent object references that are embedded in arrays) that need  
to be cleaned up to allow a complete upgrade path.  The other nice  
thing about completing upgrade/migration support is that it's a great  
way to compact the database after a long period of read/write (I have  
a 9 gig 0.6.0 database that I'll test migration on)

The one issue with migration that I'm concerned about but haven't  
looked into is whether the object reference hash limits the database  
size to the size of all saved objects in memory - or whether the  
table is only the list of source OIDs to target OIDs which should fit  
in most modern machine's memory size (100m's of objects).  I just  
haven't looked into this since last spring.

Regards,
Ian

On Nov 25, 2006, at 1:56 PM, Pierre THIERRY wrote:

> Scribit Ian Eslick dies 25/11/2006 hora 13:37:
>> Install 0.6.0, upgrade 0.5.0 -> 0.6.0 then install 0.6.1 and upgrade
>> 0.6.0->0.6.1
>
> Thansk, I'll try and see if there's anything I can do about it.
>
> BTW, is there a way to help you migrate to svn/trac, or any other
> combination of VCS/BTS?
>
> Quickly,
> Pierre
> -- 
> nowhere.man at levallois.eu.org
> OpenPGP 0xD9D50D8A
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel