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
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,
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
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
Hi,
On Wed, Feb 6, 2013 at 10:57 AM, Angela Schreiber anch...@adobe.com 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
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 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
Hi,
On Wed, Feb 6, 2013 at 12:34 PM, Angela Schreiber anch...@adobe.com 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
Hi,
On Wed, Feb 6, 2013 at 2:25 PM, Michael Marth mma...@adobe.com 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
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 from
Hi,
On Wed, Feb 6, 2013 at 3:13 PM, Angela Schreiber anch...@adobe.com 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
On 16.11.12 13:00, Jukka Zitting wrote:
Hi,
On Fri, Nov 16, 2012 at 2:48 PM, Michael Dürig mdue...@apache.org 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
Hi,
On 05.02.2013, at 11:47, Jukka Zitting
jukka.zitt...@gmail.commailto: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
Hi,
On Wed, Feb 6, 2013 at 8:04 PM, Marcel Reutegger mreut...@adobe.com 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
14 matches
Mail list logo
