I've used subversion for awhile now. From a development tool standpoint, besides a marginal savings in disk space, the best advantage of it is to be able to pull any branch and any build by looking through the log file.
Where it really shines though is when used as part of a product architecture that needs to capture or retrieve a very large number of files. We integrated it into a project that builds custom linux distros. By calling the checkout procedure we were able to download an entire linux distro worth of files onto the users thumbdrive...we keep the distro up to date by calling the update procedure. Rev stack version control may not prove extremely useful, but any time you need a very large amount of file transfers, especially to sync a client to the server, it may prove particularly handy. -- cb On 8/15/06, Richard Gaskin <[EMAIL PROTECTED]> wrote:
Frank D. Engel wrote: > The problem with using SVN (or any other modern version control > system, for that matter) with Revolution is the fact that the "source > code" (stacks) are binary files. That's okay for simple versioning, > but it is somewhat impossible to "merge" changes of multiple developers. Fortunately, in my experience it's rarely needed. Admittedly that experience may be limited: the largest team I've managed in an xTalk had only 20 developers, and most commonly the teams I work with have only 3 or 4. But with an average of about 12 product releases a year here, in each of these cases we've needed no finer granularity than the stack level. In fact, since both library stacks and UI stacks tend to deal with specific areas of functionality, from a project management standpoint there are many benefits to keeping the team member ownership tied to that level of the object model. If multiple developers need to work on a stack, it often makes sense to let one finish before sharing it with another. If the stack is large enough to warrant multiple concurrent programmers, perhaps that's really a sign to think about breaking the stack up into more easily managed parts. As Steven McConnell reminds us, adding programmers adds overhead, so that a second programmer only results in a net gain of about 50% additional productivity on average, with the rest being taken up with the overhead of coordination. Each additional programmer adds a smaller net gain, with coordination overhead increasing with team size. The rate of these diminishing returns vary from project to project, but for every project there is a point where the coordination overhead exceeds the productivity gained -- truly a suboptimal team size. :) Coordination overhead can be minimized to the degree that each programmer is working in a discrete section of the program; the fewer dependencies between modules assigned to different programmers, the lower the overhead. If a project is complex enough to warrant multiple programers, it's probably complex enough to give some serious thought to how the code is factored. If you're developing with an xTalk, chances are you'll find that stacks make a natural dividing line that not only goes with the grain of the object model, but also with effective use of that object model in applying good team management practices which not only facilitate team member communication but code maintenance as well. The only downside is that the nature of Rev's unique binary-objects-bound-with-code often means that off-the-shelf systems for text-only languages don't work as well here. The upside is that it's dirt simple to roll your own check-in/check-out mechanism -- and Chipp already has a handy one available if you're crunched for time: <http://www.altuit.com/webs/altuit2/MagicCarpetCover/default.htm> -- Richard Gaskin Managing Editor, revJournal _______________________________________________________ Rev tips, tutorials and more: http://www.revJournal.com _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
