Alex Rice wrote: >> What specifically is needed, and what are the challenges of building >> it? ... > Brian: > Developers that use CVS, Subversion etc. often use it on solo projects > as well! It's very empowering to be able to "turn back the clock" on > all or part of your code. IBM Visual Age for Java which has a > "repository" where project code could be freeze-dried, versioned, and > saved for later use or inspection. Good stuff, even working solo.
Brian's never seen Chipp's versioning auto-saver? > Richard: > If there were a version-control plugin for runrevI would surely be a > customer! I believe some ideas have been kicked around on-list for > mapping Rev stacks into a version control system. Some hurdles one > would be looking at are: > > - lack of specific hooks in IDE for controlling the script editor, the > application browser, and property inspector. What can't be hooked ? It's all exposed. It can be useful to automate code changes so you can maintain an updater utility to run those after downloading a fresh Rev. I used to do some of this in a utility called "FixMC" which wormed its way through portions of the IDE to touch up some appearance and behavior issues. Once you've idntified the specific hooks you need and how they should work I imagine RunRev would jump at the chance to put those hooks directly in the product. > - background groups - are they placed or not placed? How many cards are > they placed on? I found trying to envision a stack as a filesystem > hierarchy then background groups get confusing. Then find another mental model. :) Seriously, this comes up in HyperRESEARCH all the time. Some concepts defy tradtional hierachies. But shared backgrounds are useful objects, so there must be some way to map it into a database and it seem worth doing. > - proprietary binary stack format - depending on perspective it may be > a non-issue because we need to have version control from within the IDE > not from the filesystem. Proprieary schmoprietary. :) Everything can be atomized, disassembled, reassembled at will. Design how you want it to work and there are plenty of people who can help figure out the implementation. Running in the IDE yes, but it needn't reside in the IDE stackfiles. It could be done as a plugin. The IDE is exposed, so in the rare cases where you might want to modify it you could. But you could probably do all you need from a plugin with just backscripts and frontscripts without requiring direct modification. Then again, if you come up with a good system that could be even better if more deeply integrated in the IDE I can't imagine the folks at RunRev turning you down. My point is that it's all quite doable. It should be possible to come up with a useful collaborative system for general development in less time than you'd save working with it. A number of others here have expressed a similar interest. If an open source team was established to create such a system it may attract all the resources needed to do a good job and have fun doing it. -- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
