hi if i remember correctly the move case you mentioned below is covered by the commit hook (see VersionablePathsTest). if there are cases that don't work properly i would be glad if you could provide add a test case (patch for the fix is optional).
as far as the location of the versionable path is concerned i am not convinced that moving it the versions will add any benefit. my plan was to bind accessibility of the whole versionhistory associated with a versionable node to the permissions enforced on that very node in a given workspace. so, in other words the accessibility may change if the effective permissions change for that node (by changing the ac content or by moving around the node or any of it's ancestors). i guess what you intended to achieve by moving it to the versions themselves is to version the effective permissions themselves... but that would not require moving the paths information to the version but rather copying the complete effective permissions to the version including all effective permissions present to the whole subtree that is copied to the version node. that's IMHO not feasible. another disadvantage of moving it to the version information is that you can't determine the accessibility of the version history node. i had a similar issue when it comes to the intermediate nodes the make up the structure of the version storage and didn't find a satisfying solution. and last: you are right regarding collisions in the workspace name. but i would suggest that we just escape the name. as far as renaming/removing workspace is concerned: renaming is not supported by JCR afaik. creating new workspace as well as an existing workspace (once we actually support multi-workspace setup) could be covered by the corresponding commit hook, couldn't it? kind regards angela On 10/30/13 11:52 PM, "Tobias Bocanegra" <[email protected]> wrote: >Hi, > >oak now has rep:VersionablePaths which record the paths (per >workspace) of the versionable node. > >I think this is wrong to store this on the nt:versionHistory node, >since a node can be moved in between checkins. so I think it should be >recorded on the nt:version node. > >I also find it dangerous to just use the workspace name as property >name for the path, as it makes it harder to list the paths, if ever a >workspace is removed or renamed (not that this is supported). also, it >does not work with "funny" workspace names, such as: "jcr:uuid" :-) > >I suggest the following structure: > >/jcr:system/jcr:versionStorage/..../ [nt:versionHistory] > /1.0 [nt:version] > /rep:versionablePaths > + workspace1name "/path/..." > + workspace2name "/path/..." > + workspace3name "/path/..." > >OR a MV value: > >/jcr:system/jcr:versionStorage/..../ [nt:versionHistory] > /1.0 [nt:version] > + rep:versionablePaths [ > "workspace1name/path/", > "workspace2name/path/", > "workspace3name/path/" > ] > >WDYT? > >Regards, Toby
