On 20.1.15 4:23 , Michael Marth wrote:
Hi John,
thought about this for a while, but I don’t have a good answer.
Afaics your use case would be best served with workspaces. Until these are
implemented in Oak one possibility would be to emulate in the app as mentioned
before.
Under the hood Oak indeed uses branches that are designed to work much like git
branches, i.e. they are lightweight. However, a) these are not exposed on API
level and b) the current intended usage for those is for large transactions,
i.e. they are rather short-lived in nature.
a) could be fixed, but I am not so sure about b). The question is if the
current branch design would work fine for longer lived branches, as I expect
that there would be (much) more complicated merge logic, maybe even
app-specific merge logic.
Maybe someone else has a thoughts about this?
I can't say for the DocumentMK, but on the TarMK there is no difference
on how branches and regular revisions are stored. So long lived branches
with a lot of content do not pose a problem.
Re. merging: currently branches are merged back to trunk by first
rebasing them onto trunk and then fast forward committing them. Conflict
handling is done in the rebase phase through pluggable conflict
handlers. In the case where not all conflicts could be resolved the
operation is rejected and the conflict information (along with the
conflicting versions) is transiently annotated. Applications can already
use this to hook in their own merge logic without having to resort to
the lower level conflict hooks.
However, I think there is a missing piece when it comes to long lived
branched. For such cases you probably want to merge changes from trunk
into your branch once in a while. Such functionality is currently not
present in Oak.
Michael
Cheers
Michael
On 06 Jan 2015, at 23:41, Lukas Kahwe Smith <[email protected]> wrote:
On 06 Jan 2015, at 16:17, John Gretz <[email protected]> wrote:
Hi Michael,
What I mean is allowing for multiple authors to work in parallel on the same
set of assets and eventually merge the changes back in the main branch after
several days.In my mind this roughly translates to Jackrabbit's workspaces (or
Git branches).
I agree that this is one use case of workspaces that I would like to see
supported, ideally with a copy on write approach that would make user specific
workspaces cheap in terms of creation time and storage space.
That being said Jackrabbit 2.x (and I guess therefore JCR) is kind of limited
when it comes to merging, for example merging only changes in a parent without
also merging changes in the children is afaik not supported, which is likely
why afaik none of the big Jackrabbit based CMS use the native merging
capabilities and instead reimplement the logic in user land.
regards,
Lukas Kahwe Smith
[email protected]
