* when updating, jackrabbit at least is using this version history to
destroy as little information as possible. so if a field was updated in
the updating workspace but not in the one we update from, the changed
field is kept.
I'm not sure if I understand this. Presumably for
Hi David,
Thanks *very* much for looking into this and sharing your findings.
* cloned nodes share the version history, so checkins in either
workspace go into the same history.
This is good to know, although am I right in thinking it shouldn't affect
my current workflow (make changes in a
hi lars,
i met jukka last week and he explained me how this works, and actually
when you know where to look, it kind of is written in the spec:
* cloned nodes share the version history, so checkins in either
workspace go into the same history.
* when updating, jackrabbit at least is using this
Hi all,
Sorry to bump my own topic, but I have also come across another aspect of
cloning behaviour that I didn't expect.
Let's say workspace 'preview' contains these nodes (all nt:unstructured
with mix:referenceable, shown here with the UUID):
/a:123
/a/b:456
/a/b/c:789
When I clone /a into
