Re: Behaviour of Move Operations

2013-03-01 Thread Felix Meschberger
So you essentially say: Behaviour of the repository is best effort and we -- at the end of the day -- cannot trust the repository ? Sounds frightening. IMHO the repository should be failsafe and thus eventually solve the issue making sure we don't end up with two copies of the same node

Re: Behaviour of Move Operations

2013-03-01 Thread Michael Dürig
What Jukka is saying is that the repository gives you a choice between consistency and availability. Since both you cannot have. Michael On 1.3.13 12:40, Felix Meschberger wrote: So you essentially say: Behaviour of the repository is best effort and we -- at the end of the day -- cannot

Re: Behaviour of Move Operations

2013-03-01 Thread Felix Meschberger
Hi, Am 01.03.2013 um 13:47 schrieb Michael Dürig: What Jukka is saying is that the repository gives you a choice between consistency and availability. Since both you cannot have. I think you don't want to given the user that choice ... I'd opt for best possible availability (or probably

Re: Permission handling (Was: [jira] [Commented] (OAK-660) ReadOnlyTree: implement Object#equals and Object#hashCode)

2013-03-01 Thread Angela Schreiber
hi jukka I'm not implying that the suggested solution in OAK-660 is wrong (apologies if that was how I sounded) ack , just trying to understand why it was chosen it's not yet chosen... its work in progress and am still in the very first iteration (compared to us having up to 5 different

Re: Behaviour of Move Operations

2013-03-01 Thread Bertrand Delacretaz
On Fri, Mar 1, 2013 at 4:47 AM, Michael Dürig mdue...@apache.org wrote: ...What Jukka is saying is that the repository gives you a choice between consistency and availability. Since both you cannot have +1 to having that, as long as those choices are made clear to users. Log messages that

Re: Behaviour of Move Operations

2013-03-01 Thread Thomas Mueller
Hi, What Jukka is saying is that the repository gives you a choice between consistency and availability. Since both you cannot have. Actually, I challenge this. You can have both consistency and availability at the same time. I guess you refer to the CAP theorem, which says you can't have all of

Re: Behaviour of Move Operations

2013-03-01 Thread Thomas Mueller
Hi, One point of Oak is exactly that: to provide a sensible way for trading off consistency for availability. As far as I understood our goals, we want to have a scalable solution. While I agree that consistency is important it should however not have an impact on scenarios where it is

Re: Behaviour of Move Operations

2013-03-01 Thread Ian Boston
On 2 March 2013 01:38, Thomas Mueller muel...@adobe.com wrote: Hi, One point of Oak is exactly that: to provide a sensible way for trading off consistency for availability. As far as I understood our goals, we want to have a scalable solution. While I agree that consistency is important it