> >>Instead of the MicroKernel trying to merge changes, I would prefer if the
> >> MicroKernel would fail if a node was changed, moved or deleted after the
> >> base revision of a commit. That way, the MicroKernel API would still
> >>need
> >> a base revision in the commit call (the base revision w
Hi,
>>Instead of the MicroKernel trying to merge changes, I would prefer if the
>> MicroKernel would fail if a node was changed, moved or deleted after the
>> base revision of a commit. That way, the MicroKernel API would still
>>need
>> a base revision in the commit call (the base revision would
Hi Gardner,
> I've been experimenting a bit with Oak and ran into something I thought I
> would share, in case there is a worthwhile bug to investigate. I have
> com.adobe.granite.quickstart-2012.22-SNAPSHOT.jar, which is rather old
> now, but looks to be the latest CRX build that hangs together.
On 15.1.13 12:19, Marcel Reutegger wrote:
In a nutshell here is what I think we should do: MK.commit should fail
on all but conflicts which are trivially merged. This will not be a
problem for oak-core since oak-core applies changes to private branches
and will merge these on Session.save. Befo
> Instead of the MicroKernel trying to merge changes, I would prefer if the
> MicroKernel would fail if a node was changed, moved or deleted after the
> base revision of a commit. That way, the MicroKernel API would still need
> a base revision in the commit call (the base revision would arguably b
> In a nutshell here is what I think we should do: MK.commit should fail
> on all but conflicts which are trivially merged. This will not be a
> problem for oak-core since oak-core applies changes to private branches
> and will merge these on Session.save. Before merging, branches are
> rebased and
Hi,
> Right, when CommitCommandNew detects a concurrent commit, it retries
> the
> whole commit loop with mergeNodes etc. but I think the real problem
> regarding conflictingMove test is that CommitCommandNew#mergeNodes
> does
> not detect merge conflicts between base revision nodes and head nodes
On 15.1.13 11:19, Michael Dürig wrote:
On 15.1.13 10:23, Marcel Reutegger wrote:
I looked into why 2 tests failing in MicroKernelIT for MongoMK. One of
them is conflictingMove test. This test passes for MicroKernelImpl
and it
looks like the reason is MicroKernelImpl always commits against
Hi,
>So I guess I need to understand why it
>is important to commit against base revision in CommitCommandNew.
First, I had a really hard time understanding why we need a base revision
in the commit method.
We found a case where the base revision does make a difference, this case
is documented i
On 15.1.13 10:23, Marcel Reutegger wrote:
I looked into why 2 tests failing in MicroKernelIT for MongoMK. One of
them is conflictingMove test. This test passes for MicroKernelImpl and it
looks like the reason is MicroKernelImpl always commits against head. Take
a look at CommitBuilder around
Right, when CommitCommandNew detects a concurrent commit, it retries the
whole commit loop with mergeNodes etc. but I think the real problem
regarding conflictingMove test is that CommitCommandNew#mergeNodes does
not detect merge conflicts between base revision nodes and head nodes at
the moment. I
Hi,
On Tue, Jan 15, 2013 at 12:32 PM, Travis-CI wrote:
> View the full build log and details:
> https://travis-ci.org/apache/jackrabbit-oak/builds/4161994
"Executing your (rm -f ~/.ssh/source_rsa) took longer than 3 minutes
and was terminated."
Sounds like a Travis problem. Let's hope it resol
Hi,
Mete and I started a discussion about conflicting commits in private
emails and I'd like to move this to the dev list. feel free to jump in
and discuss.
history (most recent first):
hmm, thinking a bit more about this, I think you might be right and committing
against the given base revision
I added that addToMap flag at some point to get Copy/Move nodes tests pass
but with your recent changes, it didn't make a difference (i.e. Copy/Move
nodes test pass with & without it) so I thought it's not needed but I
didn't think about the source tree getting committed unnecessarily with a
new re
Hi,
doesn't this also change behavior? getStoredNode() was used with both
true and false before. now the nodes are put into the map unconditionally.
doesn’t that mean on copy also the source tree is put into the set of
nodes to commit?
regards
marcel
> -Original Message-
> From: meteata
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/1314
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stam
16 matches
Mail list logo
