You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by John Gretz <jg...@yahoo.com.INVALID> on 2014/12/29 17:36:03 UTC
Emulating multiple workspaces in Oak?
Hi guys,
Given that at this time Oak supports only a single workspace - are there any generally decent strategies to emulate multiple worspaces in Oak?
I think there was a suggestion in another email thread to copy the content tree for each author and use ACLs to control access. How would this strategy work during a merge back into the main tree - 'copy' does not preserver the UUIDs the same way a workspace 'clone' would in Jackrabbit...
Thanks!-John
Re: Emulating multiple workspaces in Oak?
Posted by Bruce Edge <br...@nextissuemedia.com>.
>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?
>
Assuming a) from above, if the merge logic needs to be, or is frequently
app-specific, maybe the workspace API should provide an optional merge
callback to do the actual merge. This would allow any app-specific merging
to be accomplished while still leveraging OAK workspaces, should they ever
be exposed. It seems like a wasted effort for app developers to implement
all of the workspace logic only because they have specific merge
requirements.
-Bruce
Re: Emulating multiple workspaces in Oak?
Posted by Michael Dürig <md...@apache.org>.
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 <sm...@pooteeweet.org> wrote:
>>
>>
>>> On 06 Jan 2015, at 16:17, John Gretz <jg...@yahoo.com.INVALID> 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
>> smith@pooteeweet.org
>>
>>
>>
>
Re: Emulating multiple workspaces in Oak?
Posted by Michael Marth <mm...@adobe.com>.
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?
Cheers
Michael
> On 06 Jan 2015, at 23:41, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:
>
>
>> On 06 Jan 2015, at 16:17, John Gretz <jg...@yahoo.com.INVALID> 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
> smith@pooteeweet.org
>
>
>
Re: Emulating multiple workspaces in Oak?
Posted by Lukas Kahwe Smith <sm...@pooteeweet.org>.
> On 06 Jan 2015, at 16:17, John Gretz <jg...@yahoo.com.INVALID> 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
smith@pooteeweet.org
Re: Emulating multiple workspaces in Oak?
Posted by John Gretz <jg...@yahoo.com.INVALID>.
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).
Thx!~J.
On Tuesday, January 6, 2015 5:41 AM, Michael Marth <mm...@adobe.com> wrote:
Hi John,
as you noted, copying and merging on application level is not a full replacement of workspaces. I would not even call it “emulation”.
Could you provide more information on what the problem is you want to solve? Maybe there are other possibilities.
Cheers
Michael
> On 29 Dec 2014, at 17:36, John Gretz <jg...@yahoo.com.INVALID> wrote:
>
> Hi guys,
> Given that at this time Oak supports only a single workspace - are there any generally decent strategies to emulate multiple worspaces in Oak?
> I think there was a suggestion in another email thread to copy the content tree for each author and use ACLs to control access. How would this strategy work during a merge back into the main tree - 'copy' does not preserver the UUIDs the same way a workspace 'clone' would in Jackrabbit...
> Thanks!-John
Re: Emulating multiple workspaces in Oak?
Posted by Michael Marth <mm...@adobe.com>.
Hi John,
as you noted, copying and merging on application level is not a full replacement of workspaces. I would not even call it “emulation”.
Could you provide more information on what the problem is you want to solve? Maybe there are other possibilities.
Cheers
Michael
> On 29 Dec 2014, at 17:36, John Gretz <jg...@yahoo.com.INVALID> wrote:
>
> Hi guys,
> Given that at this time Oak supports only a single workspace - are there any generally decent strategies to emulate multiple worspaces in Oak?
> I think there was a suggestion in another email thread to copy the content tree for each author and use ACLs to control access. How would this strategy work during a merge back into the main tree - 'copy' does not preserver the UUIDs the same way a workspace 'clone' would in Jackrabbit...
> Thanks!-John