The limitation would be on the set of concurrent
sessions for which we want to keep track of local commit information
for observation.
How this would work in a cluster mode. If two nodes in a cluster
perform commit with (base revision, head revision) [b1,h1] and [b1,h2]
then how would
Hi,
On Tue, Jul 23, 2013 at 11:57 AM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
How this would work in a cluster mode. If two nodes in a cluster
perform commit with (base revision, head revision) [b1,h1] and [b1,h2]
then how would observation work?.
Assuming h3 is the result of merging
On 22.7.13 13:14, Michael Dürig wrote:
- explicitly synchronise in the case of the MircorKernel based
implementations.
As Chetan mentions in the other mail, synchronisation alone does not
help here. It is still possible to have two not branches merging against
the same base revision. I.e.
On 23.7.13 10:57, Chetan Mehrotra wrote:
Its possible that for a series of changes like [b1,h1] -[ b1,h2] -
[h1,h3] the observation logic miss out seeing in between state
transition. But it would effectively see all the changes. Only changes
which get negated between missed transition would
The end result in either case is a sequence of events from b1 to h3.
If this is fine (and something which cannot be avoided) then cannot we
just make the NodeState comparable and avoid synchronizing the merge?
As that still allows us to see an ordered flow of changes.
Chetan Mehrotra
On Tue,
Hi Michael,
On Tue, Jul 23, 2013 at 2:59 PM, Michael Dürig mdue...@apache.org wrote:
It is still possible to have two not branches merging against the same base
revision. I.e. two branches that are not rebased on top of the current trunk
and merge internally. IFAICS it is also necessary for
Hi,
On Tue, Jul 23, 2013 at 12:47 PM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
The end result in either case is a sequence of events from b1 to h3.
If this is fine (and something which cannot be avoided) then cannot we
In general that can't be avoided in a fully distributed case.
Should the synchronization be done on this or some other object
which is common across branch instances as there can be multiple
instances of the branch
On Tue, Jul 23, 2013 at 5:15 PM, mdue...@apache.org wrote:
+synchronized (this) {
+rebase();
+NodeState
On 23.7.13 12:26, Chetan Mehrotra wrote:
In discussion referred to in OAK-775 it was mentioned that the event
processing would be pluggable. Is that still the case? If we make the
merge method synchronized then it cannot be avoided through a
different PostCommitHook implementation
No, not
