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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
