Avi Bryant <avi at beta4.com> wrote:
> On Fri, 19 Apr 2002, Martín Altobello wrote:
> 
> > Maybe, another way would be to use change sets... but we don't yet master
> > that issue. (If this is your choice, pointers on documentation for its use
> > would be very much apreciated).
> >
> > I believe the concept goal should be to have a centralized repository where
> > one can automatically "syncronize" before and after producing work.
> 
> We use a very simple versioning system that uses change sets to
> synchronize in the following way:
> 
> - first, your current changeset is sent via HTTP PUT to the server.  It's
> added to a directory for the project and sequentially numbered.  A fresh
> changeset is started for subsequent changes, and an email is sent out
> notifying everyone of the commit.
> 
> - then, an HTTP GET tells the server the number of the last changeset you
> have received from it.  It sends you back the concatenation of all the
> changesets it has in the project's directory since that number, along with
> doIts to increment your stored version number.  This is filed in.
> 
> It works pretty well.  The main things you have to worry about are
> separating your changes into separate changesets based on modules before
> you commit (easy with the Dual Change Sorter), and tweaking the repository
> if things go wrong (easy since it's structured just as a series of .cs
> files in a directory).   The server itself consists of a couple of small
> Ruby CGI scripts.  Authentication is done through standard HTTP basic
> auth.
> 
> It's not in great shape for distribution (stuff relating to our servers is
> hard coded in, etc), but if you're interested in using it anyway, email
> me.
> 
> Cheers,
> Avi


This seems to be a simple and  easy to implement and reliable approach.
A creative
use of the means at hand!
It might be an idea to use this later for other collaborative
development projects where 
members of this list develelop applications collaboratively over the net
in an XP
style.

HJH