version control system (was mission critical apps)

[revolution at knowledgeworks.plus.com]

Alex wrote:
>>
If one were using a filesystem representation, then it's probably an 
external requirement (i.e. not self-imposed) because the connected VC 
system uses a filesystem. A VC being for example Subversion, the newer 
CVS like system. Most VC systems are based on files and filesystems.

But in a 100% transcript model then you could throw out the filesystem 
representation then I'm sure background groups would be easier to deal 
with.
<<

I think the means to produce this version control system are actually 
within RunRev's grasp - they just don't see it yet :-)  I think there is 
quite widespread agreement on the list that it would be a significant step 
forward for Rev if there was a versioning system.

Geoff Canyon produced a stack called MCRipper that will take a metacard 
stack and convert it into an XML representation of the stack.  This 
representation could be submitted to a version control system.  Once 
inside the VCS, searches could be made on the stack (for example, running 
diff on different versions of the XML-representation of the stack). 
Indeed, one could take this even further and modify the stack as XML, and 
then re-convert ("rip" in Geoff's terms) it back into a stack. (I know 
that there is some kind of hash takes place with the length of a script, 
but that too could be implemented by them.)

I suggested this in July last year, and Alex and I had a brief interchange 
about it.

As there was no interest in it, I was going to see how far I could go with 
this myself.  Geoff's stack is extremely buggy with regard to Rev - I only 
got a license to Metacard last week so that I could try MCRipper in that 
and see if it performed better there. 

The VCS server does not even have to work on the file system model.  It 
could even be written in Rev, and could use sockets to communicate with 
the IDE.  (The file system model is really just a persistent storage that 
fits in with an application development model where code is written in 
editors and stored as text files in a directory - one reason why the 
HyperCard model was so advanced!)  If Rev could persist the versioning to 
stacks, then it is something that could (in principal) be opened up for 
developers to include versioning of data in their own apps i.e. to enable 
users to go back to previous versions of their work saved within the 
stack.

It looks to me that the absence of any ability to use Rev with a VCS is 
going to be an obstacle to it being taken seriously inside any IT 
department of a company.  (This makes me conclude that Pierre Sahores must 
be a man with great persuasive power....)

As my main project for the last twelve months has not involved Rev, I've 
just left this issue on a back burner.  But I'm glad to see it come up on 
the list again.