We have now passed the feature freeze point (2008-03-08 00:00 GMT-12)
and I have started to look for a suitable revision from which to cut the
branch.

My subversion client reports times using the CET (GMT+1) timezone so if
my math is correct all revisions created prior to 2008-03-08 13:00 CET
should be on the branch. This means that the earilest revision which can
be used for branching is

------------------------------------------------------------------------
r634896 | mikem | 2008-03-08 04:52:19 +0100 (Sat, 08 Mar 2008) | 6 lines

DERBY-3456

Clean up comments and adjust newly added code to match style of
surrounding code.

------------------------------------------------------------------------

There appears to have been 3 checkins after that:

------------------------------------------------------------------------
r634993 | djd | 2008-03-08 17:00:27 +0100 (Sat, 08 Mar 2008) | 1 line

DERBY-2109 Minor cleanup of the security code added for system permissions to ch
ange methods not to be public, add a minor comment and fix a file header
------------------------------------------------------------------------
r635115 | djd | 2008-03-09 00:56:05 +0100 (Sun, 09 Mar 2008) | 2 lines

DERBY-3435 Implements a new test class for the NetworkServerMBean and adds it to
 the management test suite. All attributes are tested, although testing of the a
ctual attribute values could be improved (see code comments). Attribute names an
d return types are always tested. 
Contributed by John H. Embretsen Email: John dot Embretsen at Sun dot com
------------------------------------------------------------------------
r635183 | kahatlen | 2008-03-09 08:33:41 +0100 (Sun, 09 Mar 2008) | 16 lines

DERBY-2911: Implement a buffer manager using java.util.concurrent classes
DERBY-3493: stress.multi times out waiting on testers with blocked testers waiti
ng on the same statement

Changed ConcurrentCache.create() to match Clock.create() more closely.

The patch basically makes ConcurrentCache.create() use
ConcurrentHashMap.get() directly instead of going through
ConcurrentCache.getEntry(), which may block until the identity has
been set by another thread. Then create() fails immediately if the
object already exists in the cache, also if another thread is in the
process of inserting the object into the cache. Since this introduced
yet another difference between find() and create() in
findOrCreateObject(), I also followed ?\195?\152ystein's suggestion from his
review of DERBY-2911 and split findOrCreateObject() into a number of
smaller methods, which I think makes the code easier to follow.

------------------------------------------------------------------------

They all seem like bug fixes that would need to be merged to the new branch
so unless I hear otherwise, I plan to cut the branch(es) from revision
635183. 

I plan to do this early on Monday (CET).


Thanks,

-- 
dt 

Reply via email to