Hi,
My take on this was: when we rebase internally anyway, why not make this
rebase available externally so branches could rebase themselves and thus
make it easier for the commit later on? AFAICS the internal rebase would
either have to be on something which pretty much resembles a private
On 6.3.13 8:23, Marcel Reutegger wrote:
Hi,
Just to further clarify, the approach where private branches are rebase
and the merged into trunk is not too different from what the initial
implementation of Microkernel.commit() (H2) tried to do: rebase and then
merge. The difference is, that we
The Buildbot has detected a new failure on builder oak-trunk while building ASF
Buildbot.
Full details are available at:
http://ci.apache.org/builders/oak-trunk/builds/1731
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: osiris_ubuntu
Build Reason: scheduler
Build Source Stamp:
Hi,
On Wed, Mar 6, 2013 at 1:49 PM, build...@apache.org wrote:
BUILD FAILED: failed compile
OSGi trouble triggered by my change in OAK-676. Fixing it now.
BR,
Jukka Zitting
Hi,
With the current implementation, that's not the case, because revision
stability with multiple cluster nodes isn't implemented yet. The idea is
that each cluster node adds revisions of other cluster nodes to its own
revision list as they are detected. Detection can be eager (when reading a
Hi,
On Wed, Mar 6, 2013 at 3:10 PM, Thomas Mueller muel...@adobe.com wrote:
With the current implementation, that's not the case, because revision
stability with multiple cluster nodes isn't implemented yet. The idea is
that each cluster node adds revisions of other cluster nodes to its own
Hi,
Do you have estimates on the potential performance impact of this?
I think in performance and memory overhead would be minimal, unless there
is a massive number of cluster nodes. The revision number consists of
[timestamp|machineId] (similar to the MongoDB ObjectId; machineId is the
same as
