Question on .rev file format

[Alex Rice]

On Tuesday, July 29, 2003, at 09:59  PM, Monte Goulding wrote:

> I haven't used CVS but it seems to be the industry standard.

CVS is great, but it's also very old and difficult to configure. 
Hopefully Subversion will replace CVS as an industry standard. 
http://subversion.tigris.org/

>  I was thinking that creating a rev based front end for CVS would be 
> ideal. I don't think
> that a Rev system would handle multiple concurrent users very well (at 
> least
> not without a great deal of work). On the other hand modelling all rev
> objects in a database could result in something unique: multi-user
> concurrent programming. Like an internet whiteboard but with stacks ;-)

It sounds appealing, but I'm having troubling imagining how RR would 
interface with a traditional version control system like CVS or 
Subversion.

I can, however, envision something closely tied to the IDE that is 
aware of the property inspector, the script editor, etc. and tracks 
changes into a "change library" as the user works. Specifically written 
for the RR IDE. Unrelated to CVS. IBM's Visual Age for Java had nice 
implementation of this concept. It was pretty slow though. Back to the 
CVS idea though. Kind of thinking out loud here:

re: Mapping between CVS and RR

Both CVS and Subversion are designed with the concept of "project as 
filesystem (or file tree)". Because a .rev stack is in essence NOT a 
filesystem, there is going to have to be a mapping between the version 
controlled filesystem and the data structure of a .rev stack.

One mapping would be a single, huge xml file with large sections of 
base-64 encoded binary objects. But that's not an improvement, 
usability wise. I have a 4.5 MB .rev stack. It's only a few images and 
the rest is cards and scripts. How big would that .rev file be as XML? 
8MB? 20MB? OK toss that idea.

A .rev stack is in part a hierarchy of mainstack/ substacks / cards / 
controls, so it seems a filesystem layout might work. But groups and 
backgrounds could present trouble (backgrounds are groups that appear 
on multiple cards). How would you represent background groups on the 
filesystem?

mainstackNameA/substackNameB/cardNameC/groupNameX/fieldNameY

Now suppose the user in the RR IDE turns on the background property of 
groupNameX, and places the grp, now background, on cardNameD. Would you 
represent it as:

mainstackNameA/substackNameB/cardNameC/groupNameX/...
mainstackNameA/substackNameB/cardNameD/groupNameX/...

Or as

mainstackNameA/substackNameB/backgrounds/groupNameX
mainstackNameA/substackNameB/cardNameC/@groupNameXLink/...
mainstackNameA/substackNameB/cardNameD/@groupNameXLink/...

Suppose the representation is worked out OK on the filesystem, with 
symlinks for group placements. But what if a CVS command-line user 
removes backgroundNames/groupNameX, or replaces the symlink 
groupNameXLink with an actual directory contents. This is a conflict, 
but CVS has no idea it's a conflict because CVS only detects conflicts 
at the sub-file level. The RR IDE user also has no idea it's a conflict 
because their copy of the .rev file is not synchronized with the RR IDE 
yet. Who is going to resolve the conflict?

It seems to me that, from the version control system's point of view, 
the single file binary .rev stack is really akin to the compiled C 
program. In a compiled language Project (C, Java, etc), the Makefile to 
build the project should be entered into CVS, but object code is never 
entered, and executables are never entered either.

So you will end up writing .rev Makefiles and a "stack compiler" script 
to get the version controlled project back into the IDE. Sounds 
difficult to setup, slow to execute and easy to break on accident.

re: Alternatives

+ Prefer separate stack files and library stacks instead of monolithic 
stack files with substacks. These separate stack files could be checked 
into CVS as binary files.

+ Use team coding where you would otherwise have multiple developers 
working on the same source code simultaneously via CVS.

+ Write a plugin for the Rev IDE that would version control scripts via 
CVS, but would not attempt to deal with the overall project structure 
and GUI layout issues.

Just food for thought. Don't get me wrong, I think source control is a 
great thing.

Alex Rice, Software Developer
Architectural Research Consultants, Inc.
http://ARCplanning.com