Subversion and online code libraries!

[David Bovill]

OK - good points all round!

Here are my use cases:

   1. Incremental backup of all code - aka Apples Leopard's Time Machine
   2. Shared code libraries - text only versioned and integrated into
   editing environment
   3. Shared "MVC controllers" - same as above
   4. Perhaps also a shared scrap book - documentation, code snippets,
   html and so forth.

I agree with Richards pros and cons with regard Rev development - we agreed
to disagree on this back when I wanted to host the MC IDE project on
sourceforge. For development projects careful chinking of code into stacks
with responsible developers is all that is needed.

It is precisely Revs strengths at RAD development that make code versioning
unecessary, and of little interest to companies focussed on RAD development
of projects. However, IMO it is precisely this advantage which leads to the
fact that there are very few high quality shared code libraries for Rev. At
least it is one of the contributing factors.

This is not a concern to an individual developer - it is quicker to roll
your own in the short term - but is SHOULD be a concern to RunRev and the
community, because over time our code base is inevitably out-competed by
open source projects with large robust well tested freely available
libraries.

IMO code versioning is not the answer it is a factor towards a solution
which can combine the best of both worlds.

To go back to the use-cases:

Incremental backup of all code - I've been using autobackup in Constellation
for a while - but it backs up the whole stack in a seperate file every few
minutes! multiply that by 50 or so stacks each with 10 or so versions and
well... a lot of storage.

How about the "binary problem"? As most of the work involved in the early
stages is code, this can be automatically saves as a text file with
hyperlinked documentation. as it is good practice to pull in images and
templates as external files in any case (at least for development) - these
can be versioned as well (not done yet).

What do you get? Well the ability to go back to any stage of your project -
you know the time when things were actually working before all those clever
changes in 15 different stacks really screwed things up :)

Shared "Code libraries" and "MVC controllers": both again text files only.
The imporatnt part is shared and shared over time - which means a few
developers working on them, and that these developers are likely to drop in
and drop out over time - this sort of thing is what cvs / svn is good at
manageing - organised chaos.

The shared scrap book is probably best doen with a simple wiki.