Sourendu Gupta wrote:

Collaborative work spanning several months, especially when it is interleaved with other collaborative threads become hard to keep track of.

I would go for a Wiki which allows ACLs and language extensions. This means that essentially anything (even more complex version control) can be plugged in. The editing interface is any editor that is configured to work with your browser but the programming language is (to begin with) somewhat limited. Reasons explained below.

What is the end result aimed for? Possible answers (multiple answers are allowed):

1. A (possibly multiply authenticated) repository of the work done so far in the form of "source/edit" documents.

2. A (possibly restricted viewing) "binary/view" version of the work done so far.

Let me explain the terms.

Source:

Refers to an editable version of the work in the preferred form for modification. In other words even if "b" is editable but is generated from "a" and cannot be re-used to generate "a" then "a" is source.

Binary:

All that is generated from source but cannot re-generate the source. This is meant for human "view"s.

It should be clear that Source should include a method for generating a Binary version by a simple command which is available on all platforms that are used for development.

Source should also include a method for verified check-in/update.

It should also be clear that while multiple types of binaries can be generated on multiple platforms these should be "equivalent from the human point of view".

Editing/Viewing/Distribution interface: (again multiple choices)

1. Mail. This is a bit dated but not absurd. Have look at "grunt" which allows "suitably-signed" messages to execute commands as the recipient user. Any editor can be used. Any versioning system can be used and so on. Viewing must be handled locally on each machine.

2. Wiki. This is a modern interface but is somewhat limited in the sense of what can be treated as source; perhaps with SWIG-style bindings to multiple languages more is possible. Also needs the repository to be central. Versioning is a bit minimal.

3. Blogs. Another modern interface. Can use arbitrary text files so any editor is OK. Must figure out how RSS/RDF can be used to automate the notification/update of material. The default "view" is essentially the source view (but perhaps with XML more is possible). Other views must be generated locally. Is distributed!

4. VCS. Any version control system does most of what is required (but it needs to be configured of course). Again "views" must be generated locally. Repository can be central or distributed.

The main advantage of Wiki's is that "view"s are generated automatically based on some simple rules. Moreover, the "view" is always directly available on the web which means that navigating the source from a human's point of view becomes simpler.

For academics having a secure/stable server for a Wiki should not be much of an issue. This is essential for a central repository based system.