Subversion and online code libraries!

[chris bohnert]

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 <ambassador at fourthworld.com> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>