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 <[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] > > >
