I guess we Revvers should be able to answer the question> "can RunRev cut the mustard in an industrial-scale context?
Would RR be suitable for a development involving 10, 20 or> more staff?".
Case in point: this afternoon I'm building a stack-based content-editing system for a 20-person team to work on one set of stack files from locations on three different continents. This is for a very specialized audience for a very specific type of content, so it also shows off how easy it is to make custom GUIs in Rev. Even the tools these contributor use to manage the system update themselves on the fly as I release new versions, keeping them up to date without breaking their workflow.
There's been a lot of discussion about how hard it is to manage team efforts using CVS, but most of that seems caused at least in part by the difficulty in mapping the C or Java workflow (hundreds of tiny text files) onto the Transcript workflow (usually a small number of stack files). There may be value in allowing every team member to modify every property of every object in real-time, but if you could work at a broader level of granularity, at the stack file level, you can craft a native solution and get 80+% of the practical benefits with less than 10% of the overhead of attempting to coerce an alien model from other systems.
I've used WebDAV when I was tech-editing a book on GoLive, but I've never used it in practice. So there may be some sort of can't-live-without-it value that just eludes my ignorance. In my limited work I found it cumbersome, but I know a lot of people love it and probably for good reason.
My point is not whether WebDAV or CVS are worthy, but whether they are worth the unsual effort needed to coerce an unusual development system like Rev into working with them.
The question becomes compounded by the tremendous ease of crafting any number of stack-base check-in/check-out systems. Scott Rossi built a fun one in probably 0.001% of the time spent developing WebDAV, and it provides the basics of stack-based check-in/check-out. He showed it here at a RevDevCon last fall and it was way cool (and almost as attractive as his custom editing palettes).
There's another advantage to supporting of group workflows at the stack level as opposed to the script or object level that goes beyond the obvious technical merit from the ease of doing so: it helps enforce healthy factoring along dividing lines based on groupings of application functionality.
One of the results of following good practice in any language is to minimize potential complexity by keeping code in discrete modules and separating it as much as possible from data and interface objects. Each element then acts as a sort of black box, like libURL, and can be maintained along parallel but separate tracks from other project components.
A stack-based approach allows one person to work on the Preferences window while another works on document-handling and a third works on a toolbar. The dividing lines of stacks usually involve discrete functionality, and working on them separately helps keep their interconnections to a minimum, greatly reducing overall complexity.
A simple stack-based check-in/check-out may not serve the needs of 100-person teams, but how many projects really require 100-person teams? (esp. condering the diminishing returns McConnell describes in his discussion of team size in "Rapid Development")
For the types of small-team projects Rev may be ideally suited for a stack-based solution is a practical alternative that can be used today. It solves the most common problems immediately, and lays the foundation for enhancements to something more well-suited for 100-person teams down the road.
-- 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
