Rebasing branches before commit

Hi, As discussed before in the context of OAK-464 the current rebase implementation in oak-core is not satisfactory. I have thus implemented two further variants: 1) in oak-core using the journal and re-applying it on top of the current trunk: https://github.com/mduerig/jackrabbit-oak/tree/

Re: build error on trunk

On 2013-01-10 14:25, Jukka Zitting wrote: Hi, On Thu, Jan 10, 2013 at 2:53 PM, Julian Reschke wrote: ...but that seems to be a Java bug (). Looks like it, yes. Works for me on Java 7. BR, Jukka Zitting Indeed. Time to bump up the JDK requi

Re: build error on trunk

Hi, On Thu, Jan 10, 2013 at 2:53 PM, Julian Reschke wrote: > ...but that seems to be a Java bug > (). Looks like it, yes. Works for me on Java 7. BR, Jukka Zitting

Re: build error on trunk

On 2013-01-10 13:05, Jukka Zitting wrote: Hi, On Mon, Jan 7, 2013 at 3:06 PM, Jukka Zitting wrote: I assume the problem only occurs when you run "mvn eclipse:eclipse", not on a normal build? As of revision 1431306 also "mvn eclipse:eclipse" should work. I simplified the build setup a bit to

Re: build error on trunk

Hi, On Mon, Jan 7, 2013 at 3:06 PM, Jukka Zitting wrote: > I assume the problem only occurs when you run "mvn eclipse:eclipse", not > on a normal build? > As of revision 1431306 also "mvn eclipse:eclipse" should work. I simplified the build setup a bit to avoid the troublesome construct. BR, J

Re: MongoMK: deleted nodes

On 10.1.13 10:53, Thomas Mueller wrote: Hi, A possible use case for a bloom filter :-) Could you tell us more about where in the code it would help? KernelNodeStore in oak-core might be a good place. This is where the positive cache for KernelNodeState resides. So I think it would sense to

Re: MongoMK: deleted nodes

Hi, A possible use case for a bloom filter :-) Could you tell us more about where in the code it would help? One thing bloom filters are not so good is when items need to be removed later on. So if we keep a bloom filter for removed node (speeding up the case where a node wasn't deleted for sure

Re: MongoMK: deleted nodes

Hi, This is only loosely related but, checking for nodes which don't exist is expensive across the stack. It currently always results in a full round trip. I think we should at some point come up with some kind of negative cache. Using a bloom filter for this would only add very little memor

Re: MongoMK: deleted nodes

This is something we discussed in last Hackathon (along with not keeping track of children in the parent) and I did a prototype at some point for both but I was running into some problems. I don't remember whether they were issues related to deleted flag or about not keeping track of children in th

MongoMK: deleted nodes

Hi, I was just thinking the way how MongoMK handles deleted nodes and I'm wondering if we should change it to make reading nodes less expensive. I understand reading a node requires checking all ancestors of that node to find out if it really exists. This is already done that way in NodeExistsCo

buildbot success in ASF Buildbot on oak-trunk

The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/1291 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stam

Re: MongoMK: CommitCommandInstructionVisitor

Right, that looks like a bug. -Mete On 1/10/13 9:27 AM, "Marcel Reutegger" wrote: >ah OK, I see. thanks for the clarification. It looks like there's a bug >in getMostRecentValidNodes() though. instead of: > >if (!commits.containsKey(revisionId) && >nodeStore.getFromCache(revisionId) != null) >

RE: MongoMK: CommitCommandInstructionVisitor

ah OK, I see. thanks for the clarification. It looks like there's a bug in getMostRecentValidNodes() though. instead of: if (!commits.containsKey(revisionId) && nodeStore.getFromCache(revisionId) != null) I think it should rather do: if (!commits.containsKey(revisionId) && nodeStore.getFromCach