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 page provider, meant to replace the RCSFileProvider, which has problems especially with Windows.

It is available from JSPWiki 1.7.0 onwards.

RefactorMe, please.

Is JSPWiki flexible enough to allow someone to write their own provider? For example we use perforce or p4 for short (

Thanks --MarkGriffith

Yes, it most certainly should be. See WritingPageProviders.


Is the VersioningFileProvider now workable on Windows?

How do I go about using it / testing it?


It should be quite functional. Just do the following:

  1. Open 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...

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

Moving from RCSFileProvider is a bit more complicated, since it involves you checking out the pages manually and storing them in the OLD directory. Could someone perhaps contribute a short script for this?

BTW, if you can live without your previous version history, just delete the RCS-subdirectory in the JSPWiki page repository, and then change the page provider. All new versions will then go to the VersioningFileProvider directory.

Though in all honesty, I haven't tested it all under Windows. There should be nothing Linux-specific in it, though... :-)


Well the neat thing (I suppose) is that I haven't managed to get the RCSFileProvider to work yet so nothings actually been checked in to the RCS directory yet. Given that though, will the VersioningFileProvider actually work either?


It should - it does not require anything extra. Just set the provider and you're set to go. (Before 1.8.0 you needed to have the RCS diff as well, though.)

The problem with RCSFileProvider is that it requires you to set up RCS, which was always designed as an UNIX tool, and none of the Windows ports have ever tried to integrate to Windows in any clean way. VersioningFileProvider does not have this problem.


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


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


What do you put as your "# The command for RCS checkin" etc when you are using VersioningFileProvider ?

Commenting them out seems to work.


You don't need the RCS checkin commands at all when you're using VersioningFileProvider. RCS is not used at all in that case.


Is VersioningFileProvider better than RCSFileProvider? Which should I use? I am on a Linux system and RCS is working fine for me, but I just started today with JSPWiki, so it really does not matter about a change...

Will they both be supported in the future?

-- JeremyC

Yes. Both will be supported in the future. My personal preference is for the RCSFileProvider, but we wrote VersioningFileProvider so that people would not need to rely on external programs. Especially for people running on Windows VersioningFileProvider is often the less problematic one.

The real difference between these two is in disk space consumption: RCSFileProvider uses far less disk space. This may be an issue when doing backups and such. --JanneJalkanen

In addition, VersioningFileProvider is far faster than RCSFileProvider, which relies on external programs to function. This can be an issue, especially if you use a lot of WebLogs.

--Janne Jalkanen

One Problem I have noticed with the VersioningFileProvider (using JSPWiki v2.1.22-cvs) is that the "last changed date" displayed at the bottom of pages is never updated as it was using the RCSFileProvider. Could this be because I did not follow the recommended procedure for switching from RCSFileProvider to VersioningFileProvider?

I have in my archives somewhere an RCSFileProvider ready tarball of the initial set of Wiki pages (at least as of some version of JSPWiki from quite long ago). If anybody wants them, just drop me a line. I am happy to contribute them if anyone thinks they would be useful to help people get going quickly with the RCSFileProvider.


How much space does VersioningFileProvider need with respect to RCSFileProvider?#

Q: What is a decent way to think about the ratio? -- MatthewSimpson

A: These pages tend to be relatively small, so disk usage isn't a huge issue -- in my opinion -- especially given the size of modern drives. It also depends upon how many times a page is revisioned. For example, the main page on JSPWiki, as of the time I am writing this, has been versioned 175 times. Let's say it fits into a 3KB file (it's not that big), which gives us 175 * 3KB = 525KB for a highly active front page (not counting disk block sizes, etc). This still isn't too bad, especially given the fact that the VersioningFileProvider is much faster than the RCSFileProvider. As for attachments, RCS is not efficient at versioning binary files -- it makes a complete copy of it just like VersioningFileProvider. I've also gone in and manually edited some of the pages on the intranet server I have running where people made some simple beginner mistakes and I didn't want to create a new version of the page and it is much easier to do that if you have separate copies of every page (this shouldn't be encouraged, by the way). If you find yourself running low on space, you could always delete some pr0n. Pic/smile.png


The RCS store of Main is 45802 bytes at the writing of this. So we would guess that the VersioningFileProvider takes about eleven times as much space as the RCSFileProvider. Take into account blocks (assume 32k blocks for FAT, for example, and you suddenly gain more:

Thus the ratio is about 87.5/1 with large block sizes...

FYI: The entire JSPWiki page repository takes at the moment 12 MBytes using RCSFileProvider, and that's with all the attachments included. But we use RCSFileProvider.

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

Has anyone written a CVS page provider? #

Funny how you need CVS to get the latest developer JSPWiki yet it supports RCS natively.

We're already using CVS for everything else, it would be great if we could (relatively) easily tie JSPWiki to it, unless this is a dumb question and CVS and RCS are close enough that this will work by default. In that case, why doesn't anyone mention it anywhere?

-- JacobShare

See CVSFileProvider Issues for more information. It is conceivable that you could use RCSFileProvider with a bunch of custom settings, as most of CVS is based on RCS.

-- JanneJalkanen


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
README.txt 66.9 kB 4 04-Feb-2006 07:18
java 15.2 kB 1 21-Feb-2005 21:48 MikeOliverAZ
« This particular version was published on 10-Feb-2004 16:22 by  
G’day (anonymous guest) My Prefs
JSPWiki v2.8.4-svn-9