# Collaborative editing

For W3C internal needs, a collaborative editing solution using CVS ahs benn developped. It is part of the standard distribution, but to use it, you need to add jigedit.jar to your CLASSPATH.

## Generic principle

Jigedit works with three spaces:

- The CVS repository
- The exported space (publishing space)
- Some optional working spaces (local editing spaces)

Due to some limitations in CVS, direct access to the repository is needed, CVS server or rsh/ssh-ed CVS will not work or only with severe limitations.

The classic scheme is a user who has a local editing space. The client gets a page from his editing space (with or without automatic synchronization with the CVS repository - latest version), edit, and sace the edits using a PUT-aware client, like Amaya.
The document is then saved on the client editing space, and this document can be commited automatically in the CVS repository, so that other editors can share the latest edits.
Then, when all the documents the client edited are ready for publication, the client goes to his PutList, and propagate the changes to the publishing space (it can, of course, be automated, using the "auto-publish" option).

Also, direct editing on the publishing space can be done, the publishing phase is then no longer needed, and the auto-commit option should be enabled, so that users editing their own space are as much as possible synchronized with the exported version.

To be able to track who is doing what, or simply to reuse the $Id$ tags of CVS, a per-user authorization scheme has to be done, but it is always good to prevent everyone to edit your website!
NOTE: To be able to change its name, cvs 1.10 has to be patched, otherwise, the name used will always be the username who started the server.

## Resource tree setup

If you have a per-user editing space, the best way it to have a specific entry point, using its name, like this:

       user - PutList
           |-  editing space

Note the PutList, which is in charge of propagating the changes to the publishing space.
If you have a shared editing space, like direct editing of the publishing space, you may have per-user entry points or just a clone of your exported web server.

## Frames settings

Basically, a leaf or container resource under Cvs control are usually like this

- FileResource-> org.w3c.jigsaw.resources.FileResource with org.w3c.jigedit.frames.CvsFileFrame
- DirectoryResource -> org.w3c.jigedit.resources.AutoLookupDirectory with org.w3c.jigsaw.frames.HTTPFrame

Also, you may have different setup if you don't want automatic cvs update (done by AutoLookupDirectory). You may also want to have a Cvs form to help you with cvs commands. This is a fake resource, so its type is org.w3c.tools.resources.FramedResource and the frame in charge of all the CVS commands is org.w3c.jigedit.cvs.CvsFrame

## Specific indexers

Of course you can setup some indexers to create the skeleton of user's accounts. As there is not (yet) support for automatic renaming with the indexers, some work has to be done manually after the automatic indexing, like the PutList file references and other things.

The following description has been done based on W3C's editing space, with a fixed Icons repository and also a fixed StyleSheets repository.