Question on .rev file format

[Joel Rees]

> 
> > > 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/
> 
> This says it handles binary files but I guess we don't really have a way of
> relating a change in the file to a change in the stack.

So binary resources (which tend to change in entirity when they change)
should be managed as the files they came from? Only actual source code
in the managed (ergo, under development) stacks?

> >
> > >  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 think if you had a save button that saved the stack as a mess of xml files
> and commited them to cvs and a button that sucked them out of cvs and built
> the stack and saved it to a temp folder that would work????
> >
> > 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.
> 
> I think that's where I was going with modelling rev objects in a database.
> That would handle the multi-developer bit but bringing in version rollback
> would make it a very complex DB.
> 
> > + Use team coding where you would otherwise have multiple developers
> > working on the same source code simultaneously via CVS.
> >
> Hmmm... now if we could only apply that to the networked world. What about
> using IM (jabber or something) to broadcast changes? If it was done well
> then any field could instantly become a chatroom ;-) A log could be
> maintained for rollback.

How about using the sandbox pattern from CVS -- each developer has
his/her own copy of everything he/she wants to look at and changes are
only registered on commits. If there is a conflict, the management
system refuses the commit and shows the committer where the conflict is
so the committer can fix it.

Figuring out what constitutes a conflict may require somewhat unique
algorithms, I suppose.

> ...

-- 
Joel Rees, programmer, Kansai Systems Group
Altech Corporation (Alpsgiken), Osaka, Japan
http://www.alpsgiken.co.jp