Kevin,

 

I do not think that the changes need to be that dramatic.  If they are, then I would certainly agree with a package namespace change.  My view is more that some refactoring will be applied to the RecordManager interface with some methods deprecated and others added.  Existing applications could continue to run within a single transaction but concurrency support would require use of new features.

 

-bryan

 


From: jdbm-developer-admin@lists.sourceforge.net [mailto:jdbm-developer-admin@lists.sourceforge.net] On Behalf Of Kevin Day
Sent: Tuesday, March 28, 2006 6:46 PM
To: JDBM Developer listserv
Subject: re[4]: [Jdbm-developer] Preliminary work on version manager i s ready to commit...

 

Bryan-

 

There's going to be an aweful lot that winds up in the dustbin on this one...  Some classes will come across (managed btree, for example), but a lot of things need changing.  I'm certainly fine with starting with existing code, but I'd rather do it in a new environment without old dependencies to worry about.

 

It seems like we are going to be changing the API semantics sufficiently to where a new package name would be appropriate, etc...  I'm certainly open to alternatives...

 

If we did an in-place update, I think I'd still want to see a completely separate folder structure for jdbm2 to keep things clean...  what do you think?

 

- K

 

 

>
Is a clean break envisioned?  I thought that we would be reusing some packages, e.g., btree, a modified recman, various things from the helper package, etc.  Why not just migrate the current code base from CVS to SVN on sourceforge?  As I understand it there are scripts for this. -bryan
 


From: jdbm-developer-admin@lists.sourceforge.net [mailto:jdbm-developer-admin@lists.sourceforge.net] On Behalf Of Kevin Day
Sent: Tuesday, March 28, 2006 6:10 PM
To: JDBM Developer listserv
Subject: re[2]: [Jdbm-developer] Preliminary work on version manager i s ready to commit...
 

My biggest reason for SVN is that CVS is slowly becoming obsolete.  If we are going to move to the new platform, then now is the time to do it, while we are making a clean break in the source...

 

- K

 

  

 
>
To me -- and these are just little pet peeves -- it's about the little
things like:

-doing a diff and reverting changes are local operations (no network
connection needed)
-reverting a change gives you back the file you were working on instead
of the "latest" version
-copying & moving files around maintains history
-caching of passwords (not necessary to use SSH key for password-less
operation)
-last but not least, the warm fuzzy feeling of using a tool that's being
maintained and developed rather than something that's decaying )

I'm fine staying with CVS but if we're going to move, I'd like to make
it an upgrade.

alex

Thompson, Bryan B. wrote:

>Kevin,
>
>It is probably too much to ask, but why SVN?  I am not struggling
>under the limits of CVS.  In any case, sourceforge has recently
>released SVN support, so there is no need to move the project if
>that is the driving factor.
>
>-bryan
>
>-----Original Message-----
>From: jdbm-developer-admin@lists.sourceforge.net
>To: JDBM Developer listserv
>Sent: 3/28/2006 4:21 PM
>Subject: re[2]: [Jdbm-developer] Preliminary work on version manager is
>ready to commit...
>
>Alex-
>
>I'm perfectly fine with the current BSD-style license - I was under the
>impression that you'd had some problems with the current license and
>corporations being able to use jdbm...
>
>I think that it's probably appropriate for this development to shift to
>SVN.
>
>As for where to store the repository (and bug tracking, wiki, etc...),
>as long as there is a solid interface with Eclipse (Which there will be
>with SVN), and the learning curve on the other tools isn't too steep,
>I'll be a happy camper.  I also think it's important to pick a location
>that will have high visibility to other developers, so the development
>effort is nice and public.
>
>I think that as the project lead that you should probably make a final
>decision here...
>
>- K
>
>    >Hi guys,
>
>On the repository side, I think we have 3-4 options:
>
>-SourceForge (CVS or SVN which is now available)
>-CodeHaus (SVN)
>-CognitiveWeb's ?
>
>I think it would be wise pick to a single hosting site and use all of
>their services (bug tracking, version control, wiki, ...)
>
>And on the licensing, I think we should try to pick a common license to
>reduce legal headaches for any user of the software.  I'm thinking along
>the lines of plain BSD, Apache or possibly EPL.   Of course copyright
>holders would retain their rigths and we would need to gather everyone's
>support for a change of licensing or possibly consider dropping code if
>we can't agree on a new license.
>
>Anything wrong with our current BSD-style license?
>
>alex
>
>Thompson, Bryan B. wrote:
>
>Kevin,
>
>Sounds interesting.  I just fixed the deadlock detection code and
>integrated it into the 2PL locking support[1].  This does not support
>intention locks (you can not describe a hierarchy of resources), but it
>should support basic 2PL.  I am working on an optimization to the
>deadlock detection code and I hope to release a beta by Monday.
>
>I take it that you mean that the notion of consistency for the design
>that you have does not use any notion of transactions within a page
>manager layer such as DBCache.  Is that of necessity or just how you
>developed it?  The DBCache [2]implementation will let you force a page
>to the db at any time, but that is probably not what you are looking
>for.  In any case, I am sure that we will get a chance to discuss the
>relationship between the version/transaction manager and page caching
>:-)
>
>I am not sure how best to proceed with respect to a jdbm2.x code base.
>Anything that is derived from jdbm1.x is of course under the existing
>license terms, but new modules can be under a different license as long
>as they do not share code or have explicit copyright grants from all
>authors.  
>
>-bryan
>
>[1]
><http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-concurren
>t/index.html>
>http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-concurrent
>/index.html
>[2]
><http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-dbcache>
>http://proto.cognitiveweb.org/projects/cweb/multiproject/cweb-dbcache
>/index.html
>
>
>
>
>From:  <mailto:jdbm-developer-admin@lists.sourceforge.net>
>jdbm-developer-admin@lists.sourceforge.net
><mailto:jdbm-developer-admin@lists.sourceforge.net>
>[mailto:jdbm-developer-admin@lists.sourceforge.net] On Behalf Of Kevin
>Day
>Sent: Thursday, March 23, 2006 10:16 AM
>To: JDBM Developer listserv
>Subject: [Jdbm-developer] Preliminary work on version manager is ready
>to commit...
>
>
>Gents-
>
>
>
>OK - finally had time to finish up work on the proof of concept for the
>version and transaction manager for jdbm2.  This is just proof of
>concept, but I'd like to ask you guys to take a look at the unit test
>and let me know if you see anything that you think should be tested for
>that isn't, etc...
>
>
>
>The current implementation has been tested for transaction isolation for
>overlapping transactions, properly purging of unneeded data, etc...
>
>
>
>The algorithm has been designed with aborts and roll-back in mind, but I
>have not put unit tests in place for that yet (tomorrow maybe), and the
>code for properly purging aborted tx from the transaction manager still
>needs to be put in place (Basically, aborted tx can't be removed from
>the master transaction list until the garbage collector has run one full
>iteration).
>
>
>
>The algorithms are designed to allow writing to the data store at any
>point - regardless of whether a transaction is comitted or not.  A
>warning:  this is *very* different from the dbCache design, which relies
>on only writing comitted data to the data store (or jumping through
>hoops to allow for roll-back if uncomitted data is written to the
>store).
>
>
>
>The current proof of concept system has no caching - all changes to the
>data are written directly to the store (which is in-memory right now -
>nothing to disk, etc...).  This means that there is absolutely no
>distinction between regular transactions and very long transactions -
>the algorithm treats them all the same (and works :-)  ).  This means
>that handling of VLR will become a caching policy implementation detail
>- not something that requires special handling in the transaction or
>version managers (this is a good thing, I think).
>
>
>
>
>
>So - where should I commit the code to?  Alex - should I create a
>separate folder for jdbm2 exploratory stuff in the jdbm SF project?
>Should we create a new SF project (for licensing reasons)?
>
>
>
>Thanks,
>
>
>
>- K
>
>
>
>
>
>Kevin Day
>Trumpet, Inc.
><http://www.trumpetinc.com> www.trumpetinc.com
><mailto:kevin@trumpetinc.com> kevin@trumpetinc.com
>602-438-7030
>
>------------------------------------------------------- This SF.Net
>email is sponsored by xPML, a groundbreaking scripting language that
>extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding
>territory!
><http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=12164
>2>
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________ Jdbm-developer mailing
>list  <mailto:Jdbm-developer@lists.sourceforge.net>
>Jdbm-developer@lists.sourceforge.net
><https://lists.sourceforge.net/lists/listinfo/jdbm-developer>
>https://lists.sourceforge.net/lists/listinfo/jdbm-developer
><
>    
>------------------------------------------------------- This SF.Net
>email is sponsored by xPML, a groundbreaking scripting language that
>extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding
>territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________ Jdbm-developer mailing
>list Jdbm-developer@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/jdbm-developer
>
>
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jdbm-developer mailing list
Jdbm-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdbm-developer

<
<

 

------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbm-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdbm-developer