Hi,
On Wed, Feb 6, 2013 at 8:04 PM, Marcel Reutegger wrote:
> They are easy to fix but very difficult to detect and diagnose. No exception
> is thrown,
> just the behavior is unexpected. I think this is quite dangerous, since the
> spec is
> IMO quite clear about this
> http://www.day.com/specs
Hi,
On 05.02.2013, at 11:47, "Jukka Zitting"
mailto:jukka.zitt...@gmail.com>> wrote:
Do you have examples of where the new behavior would be troublesome
for existing code (not just new test cases)? The assumption from the
earlier discussion was that such cases should be pretty rare and easy
to f
On 16.11.12 13:00, Jukka Zitting wrote:
Hi,
On Fri, Nov 16, 2012 at 2:48 PM, Michael Dürig wrote:
I was having a look at KernelRootBuilder.update() which saves pending
changes down to a branch in the Microkernel after a certain threshold in the
number of changes. I was wondering if this has
Hi,
On Wed, Feb 6, 2013 at 3:13 PM, Angela Schreiber wrote:
>> Wouldn't any other "version history -> path in workspace" mapping face
>> the same problem?
>
> no.
Can you describe the mapping you had in mind? How does it address this
problem with "lost" version histories?
>> From the top of my
hi jukka
Wouldn't any other "version history -> path in workspace" mapping face
the same problem?
no.
From the top of my head I'd treat such "lost" version histories as
admin-only content until someone "re-connects" them by cloning a
versionable node from another workspace or importing one
On 6.2.13 13:29, Michael Marth wrote:
Hi Michael,
On Jan 29, 2013, at 12:43 PM, Michael Dürig wrote:
Nice idea!! This puts clients into control over the trade off between
consistency and availability by choosing the "right" journal to commit to.
With "clients" you mean oak-core, right? Or w
Hi,
On Wed, Feb 6, 2013 at 2:25 PM, Michael Marth wrote:
> Excuse my ignorance, but I never came across the concept of a tree of journals
> before. Is this an entirely new idea or has this been around somewhere?
It hasn't come up in exactly the same format before. The inspiration
comes from gene
Hi Michael,
On Jan 29, 2013, at 12:43 PM, Michael Dürig wrote:
Nice idea!! This puts clients into control over the trade off between
consistency and availability by choosing the "right" journal to commit to.
With "clients" you mean oak-core, right? Or would you leak this detail through
to high
Hi Jukka,
interesting proposal!
Excuse my ignorance, but I never came across the concept of a tree of journals
before. Is this an entirely new idea or has this been around somewhere?
One other question I had: how does this proposal relate to the proposal for a
ID-based MK API [1]. I realize th
Hi,
On Wed, Feb 6, 2013 at 12:34 PM, Angela Schreiber wrote:
>> I would simply use UUID lookups for that. [...]
>
> that doesn't work because we have to deal with "lost"
> content in the version store i.e. version histories
> whose versionable node has been removed... basically
> that's the fund
hi jukka
I would simply use UUID lookups for that. [...]
that doesn't work because we have to deal with "lost"
content in the version store i.e. version histories
whose versionable node has been removed... basically
that's the fundamental problem behind the various issues
we are facing with t
fine with me.
angela
On 2/6/13 12:04 PM, Michael Dürig wrote:
Hi,
Before jumping to conclusion here I'd like to get a clearer picture how
we address workspace support. In OAK-118 we decided to stick with a
single workspace "for now". I think it is high time we revisit that
since it block other
Hi,
On Wed, Feb 6, 2013 at 10:57 AM, Angela Schreiber wrote:
> in order to address OAK-444 without excessive uuid resolution
> upon access control evaluation i create a separate commit hook
> that keeps track of the path of versionable nodes .
I would simply use UUID lookups for that. The UUID i
Hi,
Before jumping to conclusion here I'd like to get a clearer picture how
we address workspace support. In OAK-118 we decided to stick with a
single workspace "for now". I think it is high time we revisit that
since it block other things as well (e.g. OAK-453).
I suggest we schedule a ses
On 6.2.13 10:34, Angela Schreiber wrote:
hi michael
passing in a default parameter for method that returns boolean
looks pretty awkward to me and i somewhat dislike the lengthy
names because the of the utility was to make the code readable.
but i will add some javadoc both in TreeUtil and in N
hi michael
passing in a default parameter for method that returns boolean
looks pretty awkward to me and i somewhat dislike the lengthy
names because the of the utility was to make the code readable.
but i will add some javadoc both in TreeUtil and in NodeUtil.
angela
On 2/6/13 11:28 AM, Michael
On 6.2.13 10:03, ang...@apache.org wrote:
@@ -59,4 +60,9 @@ public final class TreeUtil {
return null;
}
}
+
+public static boolean getBoolean(Tree tree, String propertyName) {
+PropertyState property = tree.getProperty(propertyName);
+return pr
hi
in order to address OAK-444 without excessive uuid resolution
upon access control evaluation i create a separate commit hook
that keeps track of the path of versionable nodes .
since the version information is defined to be 'global' for a
given respository while the versionable path might dif
18 matches
Mail list logo
