Versioning now available

[Janne Jalkanen <ja...@ecyrd.com>]

Hi folks!

One of the major missing components so far has been versioning.   
Thanks to holidays (and the help of the in-laws, yay!) I just landed  
an implementation which seems to work, and also provides gappy  
versioning ;-). It's suboptimal ATM, but please do test it out. I  
think we accidentally deleted a bunch of useful versioning tests with  
VersioningFileProviderTest, so we might want to try to backport some  
of those.

(After a *long* deliberation I chose not to use JCR versioning.  
Reasons are detailed in doc/README - JCR Changes.txt.)

Now I think all the major pieces are in place.

/Janne

Re: Versioning now available

[Janne Jalkanen <ja...@ecyrd.com>]

>> * Could checkout() be made part of the page-locking process? Could  
>> the
>> act of placing a PageLock prompt a checkout() operation?
>
> req's reworking of pagelocks; embedded use does not require locking.  
> They are conceptually different also, since pagelock can last for a  
> long time.

Also, to continue in this vein, JCR also supports locking as a  
separate thing, and that's conceptually even more different than  
PageLocks. I haven't yet figured out a good use for the JCR locking in  
JSPWiki context. It has a couple of downsides:

* JCR locks expire randomly.  That is, most of the time they do not  
expire, but there is usually a cleanup process which randomly throws  
away old locks. JCR defines no way to configure this.
* JCR lock tokens require a lot of safekeeping; if you lose one, you  
can't unlock.
* JCR locks don't have the necessary metadata to replace PageLocks;  
those would need to be managed manually anyway.
* PageLocks can be broken trivially programmatically; JCR locks  
cannot, unless you have the token.

JCR locking is really meant to prevent concurrent modification by  
multiple accessors.  I think we might find them very useful when we  
enable clustering, but before then I'm not too sure what to use them  
for.

/Janne

Re: Versioning now available

[Janne Jalkanen <ja...@ecyrd.com>]

> * Re: import/export. What's the issue about /jcr:system being
> unmodifiable? Not sure I understand.

Explicitly forbidden by JSR-170. All JCR version data resides under / 
jcr:system/jcr:versionStorage. Hence it is unmodifiable. See  
Workspace.export().

Playback ops not possible either (no way to explicitly preseve uuid &  
e.g. creation date. See https://issues.apache.org/jira/browse/JCR-1972.)

> * Re: subpages and subtrees. Might there be a way to implement
> sub-pages in a fashion that doesn't make them subtrees of their parent
> JCR page? Flat physical directory maybe? Split pages from the
> "containers" that enclose their sub-pages?

I thought about it, but I chose this way because it feels more logical  
to group them together for e.g. move, rename and export ops. If they  
are placed in a separate dir, then it makes sense to reference by  
uuid, and that gets a bit messy structure-wise.

> * Could checkout() be made part of the page-locking process? Could the
> act of placing a PageLock prompt a checkout() operation?

req's reworking of pagelocks; embedded use does not require locking.  
They are conceptually different also, since pagelock can last for a  
long time.

/janne, typing with single hand agn, so please excuse brevity

Re: Versioning now available

[Andrew Jaquith <an...@gmail.com>]

Took a look at the JCR notes. I don't know too much about JCR. Thought
I'd lob out some fairly naive questions:

* Re: import/export. What's the issue about /jcr:system being
unmodifiable? Not sure I understand.
* Re: subpages and subtrees. Might there be a way to implement
sub-pages in a fashion that doesn't make them subtrees of their parent
JCR page? Flat physical directory maybe? Split pages from the
"containers" that enclose their sub-pages?
* Could checkout() be made part of the page-locking process? Could the
act of placing a PageLock prompt a checkout() operation?

I know you've already committed lots of code, but I thought I'd throw
these questions out there in case it helps.

All that aside, the prospect of versioning making it into the first
Apache release in ANY form is awesome.

Andrew

On Wed, Jul 22, 2009 at 5:52 PM, Andrew
Jaquith<an...@gmail.com> wrote:
> Great news. Who knew your in-laws could code? :)
>
> On Jul 22, 2009, at 14:06, Janne Jalkanen <ja...@ecyrd.com> wrote:
>
>> Hi folks!
>>
>> One of the major missing components so far has been versioning.  Thanks to
>> holidays (and the help of the in-laws, yay!) I just landed an implementation
>> which seems to work, and also provides gappy versioning ;-). It's suboptimal
>> ATM, but please do test it out. I think we accidentally deleted a bunch of
>> useful versioning tests with VersioningFileProviderTest, so we might want to
>> try to backport some of those.
>>
>> (After a *long* deliberation I chose not to use JCR versioning. Reasons
>> are detailed in doc/README - JCR Changes.txt.)
>>
>> Now I think all the major pieces are in place.
>>
>> /Janne
>

Re: Versioning now available

[Andrew Jaquith <an...@gmail.com>]

Great news. Who knew your in-laws could code? :)

On Jul 22, 2009, at 14:06, Janne Jalkanen <ja...@ecyrd.com>  
wrote:

> Hi folks!
>
> One of the major missing components so far has been versioning.   
> Thanks to holidays (and the help of the in-laws, yay!) I just landed  
> an implementation which seems to work, and also provides gappy  
> versioning ;-). It's suboptimal ATM, but please do test it out. I  
> think we accidentally deleted a bunch of useful versioning tests  
> with VersioningFileProviderTest, so we might want to try to backport  
> some of those.
>
> (After a *long* deliberation I chose not to use JCR versioning.  
> Reasons are detailed in doc/README - JCR Changes.txt.)
>
> Now I think all the major pieces are in place.
>
> /Janne