Hi, On Thu, Apr 10, 2008 at 8:19 AM, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > However, I see no other problems that would prevent us from using > > JCR's versioning, and I think that this problem is solvable (must have > > been solved in the RCS page provider anyway, I guess/hope). > > Actually, I was thinking that maybe we should just skip the use of JCR > versioning, and do things the same way we've done before (i.e. having a > separate directory (or node) where we can put our versions.)
That's a valid approach. The nice part of the built-in versioning feature is that it takes care of all the required copying when creating new versions or restoring old ones. Also, JCR versioning guarantees that a checked-in version is never modified even by mistake. However, JCR versioning can be rather challenging to implement especially if you're looking at using a custom light-weight JCR implementation instead of an existing repository like Jackrabbit. And even current Jackrabbit has problems with migrating version histories from one repository to another. > JCR versioning adds some annoying artifacts in the way that you have to > deal when accessing the repository (checkin/checkout), and I was kinda > hoping we could do without them. I haven't yet figured out a way what is > the advantage of using JCR versioning. Beside the above points, one major use case for JCR versioning is support for staging-live scenarios, where you author content in one (staging) workspace and use the versioning feature to push content to another (live) workspace once it's ready to be published. BR, Jukka Zitting
