There is no [CVS] File Provider in JSPWiki yet (v1.6.9).  Share your ideas here...

(Discussion moved from [TODOList]).

----

We've written a working CVS file provider at the University of Calgary. You can find it at [AntCvsFileProvider]. This provider is based on ANT which in turn provides a java interface to a local CVS client binary. It is very useful if you already have a CVS server running and want to use it for version control. Our provider is very easy to install. 

-- [KrisRead] and [ThomasChau]  June 3 2003

----

CVS support. Volunteer! RCSFileProvider -> CVSFileProvider & set the jspwiki.pageProvider... Yes/no/maybe? - [MikaelHonkala]

Tip: I used the java cvs package from netbeans recently, that could provide for a pure java solution- even with a remote cvs server (Volunteer). - BobSchulze

What's the advantage of CVS over RCS? Would a CVSFileProvider have additional functionality? Or is this desirable because many people have CVS already set up? - [MahlenMorris]

The reason why we don't have CVSFileProvider is simply because CVS requires a 
separate repository to be set up, and at the time I felt that anything that 
requires secondary setup in addition to Wiki would be unnecessary burden to 
the user - especially since RCSFileProvider already gives practically all
required functionality.   Note that using RCSFileProvider requires no setup
whatsoever, if you just have the RCS binaries installed.
(In fact, making a CVSFileProvider should be real easy, in 
theory you should be able to just set the proper values for RCSFileProvider in
jspwiki.properties to get it to use CVS instead of RCS.) But feel free to
write a CVSFileProvider =).  --[JanneJalkanen]

Mostly because we have CVS already set up. Another half-baked idea I had was
to use a central CVS repository as a "master", with local files (on, say,
laptops) acting as local show-and-tell copies (at, say, a client meeting).
CVS could then be used to "replicate" offline changes. But maybe it is
better to just get Bluetooth GPRS phones to everybody.
--[MikaelHonkala]

It is not a bad idea, and certainly workable.  But what would you do in case
of conflicts?  It would be kinda hard for Wiki to actually understand
them.

On the other hand, you ''could'' just have a local FileSystemProvider on your
laptop, and synchronize manually with a remote CVS repository, handling
all conflicts manually...  Yeah.  Perhaps there is some value in a 
CVSFileProvider... 
   --[JanneJalkanen]

But in that case, you wouldn't need a separate CVSFileProvider, since FileProvider and manual sync with CVS would be enough?
  --[MikaelHonkala]

For the main server it would be useful, since you wouldn't need to run manual sync with that server.  For local copies FileSystemProvider would be enough.
Ngh.  You'd still need to be able to resolve conflicts, though.  On the other hand, they'd be visible on normal Wiki pages as text, so they wouldn't be impossible to find.
  --[JanneJalkanen]

For CVS there are great diff viewers available (ViewCVS for example). Yes, it needs extra setup, but thats worth. 
  --[BobSchulze]

The problem, of course, being that typically people do not understand conflict management.  So it would be kinda odd to put in a complex conflict management system only few people understand and would use.  Would it actually be worth it?  Looking at the current statistics of this site, conflicts occur extremely rarely (once per 10,000 edits or less).  Would it really be worth it, then?

-- [JanneJalkanen], 29.11.2002

I think manual conflict resolution would be fine.  Those who are interested enough to use such a setup (me) would be satisfied with manually syncing (at least for now).  I definitely would love to be able to take my with me wiki offline.

-- KenLiu 20-Jan-2003