Re: Unix philosophy under the gun?

[David Fuller]

"Greg A. Woods" wrote:
> 
> [ On Friday, August 3, 2001 at 14:51:24 (-0400), David Fuller wrote: ]
> > Subject: Re: Unix philosophy under the gun?
> >
> > The glue in question involves reporting, logging, replication/mirroring,
> > and integration with other products (such as bug/feature tracking).
> 
> Did you do a cost-benefit analysis of those features too?
> 
> Did you also do a true and in-depth total cost of ownership analysis for
> the the alternative solutions over the lifetime of the projects
> involved?  There are a lot of hidden costs that many people miss and
> others prefer to ignore....
> 

First bear in mind that I said 'sample' numbers.  While we tried to
include everything we could think of in our analysis, the full analysis
is yet to come.

> I'll bet you could drop down any of them to a level of functionality
> that would exatly meet your needs but where the costs of implementing
> the necessary CVS glue would be lower than any thing else every time.
> I.e. I'll bet even though you're getting more up-front features for less
> money in some off-the-shelf thing, they're not all features you need and
> in the end you're actually paying more money for those things you don't
> need.

Actually, no.  Most of the features we do need, some are required by our
customers.  What we actually need is a system that would support 5
different levels of process we identified as necessary to cover the
range of projects we deal with.  CVS could easily cover the lowest 2
levels, and with little work could cover the third, but the cost of the
highest 2 levels was what took a significant amount of effort.

> (Of course the same could be said of Aegis or other freeware tools, or
> even of some commercial tools that would need similar integration, such
> as BitKeeper.)

Absolutely true.

> 
> >  And
> > why shouldn't CVS be able to integrate with 'a decent build system'?  I
> > wouldn't expect CVS to be a build system, but to work with one would be
> > nice.  And yes, I'm sure it can, but it would take time to get that
> > integration in there.
> 
> Indeed CVS can be "integrated" with the build system!  I have it built
> into Automake and Autoconf.....  I just update the release identifier in
> my "configure.in" file (and commit it of course) and then type "make
> release".  A fully tested source archive with all necessary intermediate
> products included comes out the other end and my repository has a new
> tag now marking the event.  It's not magic.  It's not even more than a
> few dozen lines of write-once shell script in a portable Makefile
> produced automatically for every one of my projects by my customised
> version of automake!
> 
> That's release management and builds (source tars _are_ my product) all
> rolled into one!

Customized version of automake?  Interesting.  Yet another thing to
maintain...  I would be interested in seeing your build system.  The
availability of tools built by others would greatly help to reduce the
cost of CVS in a larger system.  I'm sure these things have all been
built before, unfortunately most people don't post them on the web,
don't update them, or you simply can't find them.

> > Here's a question.  What is there to prevent CVS from becoming modular
> > to the same degree as Apache?  Certainly time is a factor.  I'd love to
> > work on that one if only I had more time (24 hours is never enough).
> 
> That's putting the cart so far in front of the horse that the horse
> can't even see it!  ;-)
> 
Huh?  You really lost me on that one.  An examination of the CVS system
and knowledge of the Apache module architecture could probably result in
a similar architecture for CVS.  It's all just a matter of time...

-- David F.