David Bovill wrote: >> On Tue, Mar 4, 2008 at 11:58 AM, Richard Gaskin >> > I've thought about the type of scenarios described here, in >> > which two or more programmers may be assigned to work on the >> > same stack, but to be honest to me that seems less a technical >> > challenge than an architectural and human resources one >> > On 05/03/2008, Chipp Walters <chipp at chipp.com> wrote: >> Agreed 100%. >> >> Key word in the below sentence is "architectural". IMO, a properly >> designed architecture can handle multiple programmers, each working >> on their own stacks. > > Agreed as well - but in the context of your own or a relatively small > groups productivity. That is it is not worth going down the path of > svn or finer granularity for your own productivity, unless perhaps > you and your team are already familiar with such tools and working > practices based on other languages.
If you're bringing in developers familiar with other languages, the learning curve for something as simple as Magic Carpet is trivial compared to the time to learn how to use Rev itself effectively (not to mention the additional time needed to figure out a scheme for integrating Rev with something like SVN, and the day-to-day overhead inherent in using such a scheme).
Rev isn't just another language. It's also an object model and file format, all bound together to create a unique way of working. I'm not sure tools designed for other languages can always be expected to integrate gracefully well a Rev workflow.
Admittedly my own experience is perhaps limited, having managed xTalk-based projects with only 25 developers at most. But that's a fair number of developers, for a project whose budget was well over a million dollars. Projects of that scope are rare, but it's worth noting that it was done with a stack-based check-in/check-out, with significant cost savings to both our team and the client.
That said, I suppose if we look at all possible scenarios we could find circumstances for which a finer level of granularity may have a positive ROI. We've found no significant limitations with stack-based check-in/check-out thus far, but in the infinite range of all possibilities I can't rule out that we might be able to lower our costs even more with a different way of working.
Chipp's Magic Carpet is a very capable stack-level tool available now, and being such a with-the-grain way of working with Rev it's not too hard to craft on of your own if you need to.
If tools supporting a finer level of granularity exist and are demonstrated to provide a higher ROI than the many projects delivered with stack-based tools, I'd certainly be interested in checking them out (if you'll pardon the pun).
-- Richard Gaskin Managing Editor, revJournal _______________________________________________________ Rev tips, tutorials and more: http://www.revJournal.com _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
