This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

VersioningFileProvider is a new PageProvider, meant to replace the RCSFileProvider, which has problems especially with Windows.

It is available from JSPWiki 1.7.0 onwards. To use it, edit the jspwiki.properties file as follows:

  1. Change the jspwiki.pageProvider to VersioningFileProvider with no leading or trailing spaces!!
  2. Confirm the line jspwiki.fileSystemProvider.pageDir = some path is correct for your system
  3. Add a line jspwiki.versioningFileProvider.pageDir = some other path to the file, although it doesn't seem to be used for anything...

see also FileProviderComparing, FileProviderMoving


Is the VersioningFileProvider now workable on Windows?

How do I go about using it / testing it?

--MattMower

It should be quite functional. Just do the following:

  1. Open jspwiki.properties file in your favorite editor
  2. change the jspwiki.pageProvider property to VersioningFileProvider (the former version of this page called for "com.ecyrd.jspwiki.VersioningFileProvider").
  3. a few lines below you have to set the directory where the VersioningFileProvider stores its files. Just change the property jspwiki.fileSystemProvider.pageDir according to the file and directory naming conventions...
--GernotStarke

Now you should be set (at least for version 2.0.0 alpha).

--JanneJalkanen


I seem to remember a Java port of the CVS client, I wonder if that had a diff client that could be re-used...

--MattMower

Since 1.8.0, we are using an internal Java diff routine, so we now require no other software =).

--JanneJalkanen


Setting a maximum number of versions to store?#

Something that might be useful would be a property that can be set expressing the maximum number of revisions stored. If this value were set to 10, then when the 11th version were added it could automatically delete the first. I suppose the rest of the files could be then renamed (2 to 1, 3, to 2, etc) but I'm not sure I see much need for that. That might reduce some of the administration necessary. I don't see a whole lot of interest with maintaining the ability to go back to the absolute first version of something. I find that being able to back a few to maybe a dozen is sufficient, but YMMV, I suppose.

-- RobSeegel

Nice idea. It would make sense to enable something like that for intranet wikis and so on; on public wikis you really want rollback to any version (to make sure you can get over from WikiGraffiti).

-- JanneJalkanen

Is this available (vJSPWiki v2.2.13) ?

Right now I have pages with more than 150 revisions !

-- RealGagnon


When I try to use VersioningFileProvider on my wiki, the system gave me

an error that An unknown exception java.lang.NullPointerException was caught by Error.jsp#

Who has idea why it is?

-- Dongsehng


Hi ... even i am having the same problems with it

An unknown exception java.lang.NullPointerException was caught by Error.jsp

does anybody know whats happening??

Thanks


Arite ... the null pointer exception is now solved... u need to do the following:

1. jspwiki.pageProvider = VersioningFileProvider

2. jspwiki.fileSystemProvider.pageDir = path where all the wiki pages are... it creates a subdirectory here for storing the older versions...

3. jspwiki.versioningFileProvider.pageDir = some path

and it works fine for me ...

But can someone tell me if you have managed to get the AntCvsFileProvider running fine with the latest version of JSPwiki?? thanks

AJ


This is also needed (at least in 2.3.92):

4. jspwiki.usePageCache = true

TN


I found that if there is a space at the end of "jspwiki.pageProvider = VersioningFileProvider " then you get the exception "An unknown exception java.lang.NullPointerException was caught by Error.jsp". Make sure there are no spaces at the end.

DH


I am running v2052 (stable) using VersioningFileProvider. Is there any way to get rid of older versions of a page? Since I found the Preview would often lock up my process with the "Oops you are in conflict" msg, I took to Saving each time, and now have 200 versions :-) I probably still won't use Preview and will end up with another 200, so I would like a way to delete them.

thanks

VS


I am looking for an easy way to mark certain versions of a wiki page. JSPWiki always shows the latest version of a page, even if that information is 'under construction'. See VersionLabel for more discussion. -- DF


Hi guys, I've been trying to get versioning working without success.

jspwiki.pageProvider=VersioningFileProvider

Then I get the error

ERROR com.ecyrd.jspwiki.providers.CachingProvider - Unable to locate provider class VersioningFileProvider
java.lang.ClassNoFoundException: Class not found in search path!

Ideas anybody ?

JJH

Check that you don't have extra spaces around the "VersioningFileProvider".

-- JanneJalkanen

Hey, thanks mate that's sorted it. I thought that I'd previously checked that I've read it above, maybe I've been at this keyboard for too long.

So that now appear to work OK, for the record.
Fedora Core 2
Tomcat 5.5.4
Java 1.5.0
JSP wiki 2.1.115.alpha

JJH



I am using the file system versioning and it seems to work quite well. One thing I think would add some value is to implement something that is similar to feature branches. This would allow a user to work on a draft copy and continually save, without causing version clutter. For example:

  • The last check in version of a page might be 1.2
  • I edit the page but suspect that I won't have it complete in the short term, so will need to save an intermediate copy
  • Rather than click "save" I choose to save a draft copy (equivalent to a private branch)
  • This new copy is saved in the file system as 1.2.0.1 - nobody else can see it except me
  • I make some more changes, and save again as 1.2.0.2
  • Now my work is complete, so I choose to "merge" my changes back to the main trunk as 1.3
  • The feature branch can now be discarded, reducing the file system clutter

Now, the tricky part is how to handle the merge. Some options are:

  • apply my changes back to the main trunk, blowing away any subsequent edits that another user makes (easiest)
  • deny the merge (easy, but impractical)
  • perform some sort of smart merge (harder to implement in software)

If the first option was implemetned and I was a nice person, I would just manually merge the content myself. This would probably be the easiest approach to take in the beginning. You could also limit the user of private branches to certain trusted users.

What do you think?

--DavidC

--DavidC, 09-Sep-2006

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
txt
README.txt 66.9 kB 4 04-Feb-2006 07:18 148.221.80.109
java
VersioningFileProvider.java 15.2 kB 1 21-Feb-2005 21:48 MikeOliverAZ
« This particular version was published on 09-Sep-2006 07:33 by DavidC.  
G’day (anonymous guest) My Prefs
JSPWiki v2.8.4-svn-9