Re: Unix philosophy under the gun?

[David Fuller]

Matthew Riechers wrote:
> 
> David Fuller wrote:
> >
> > Matthew Riechers wrote:
> > >
> > > UNIX tends to blur users and developers together, which is a Good Thing
> > > for developers :)
> >
> > Ah, but this is not necessarily a Good Thing for businesses.  A business
> > may not be able to afford to let their developers take the time to build
> > the glue they need.  Which is why "the whole package and a pickle too"
> > is becoming more popular.  I've been looking at using CVS at my company,
> > and have some projects working in it.  But to roll it out for our whole
> > department isn't likely to happen because it would take our developers
> > time to get all those 'glue' pieces in place.  We ran some sample
> > numbers and it would likely cost us more in the long run to use CVS than
> > some $1000/seat software because of all the glue we would need.
> 
> That problem is one of integration with projects that have *never had
> revision control*. I've found integration to be a messy, difficult
> process, but with modest planning it isn't impossible, and the benefits
> are an order of magnitude better than the previous situation, therefore
> it is worth it whether you pay $1k/seat for some product or just use
> CVS. I think the 'glue' your talking about is really 'a decent build
> system', and that's something that CVS won't help you with. You're
> trying to compare apples and oranges.

Not necessarily.  We were mostly looking at it from a clean slate, all
new projects.  Existing projects were not figured into our estimates.

The glue in question involves reporting, logging, replication/mirroring,
and integration with other products (such as bug/feature tracking).  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.

> > Or, it means that the tools have to be built to be modular and easily
> > extensible.  Look at Apache.  Check out the list of modules for Apache.
> > Apache does HTTP well, but with all the modules available for it Apache
> > has become much more.
> 
> True. However, the (only?) VC system that implements this model seems to
> be subversion, which hasn't made it off the ground yet.

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).

> > It takes serious interest and commitment to learn how to glue those
> > things together.  Then you have the problem of maintainability.  If you
> > have to build those glue pieces in house that also means you have to
> > maintain them in house.
> 
> What 'glue' are you talking about? One-liners or entire build systems?
> CVS is only one component of either of these, so it only contributes to
> part of the maintainability. If you're using an all-in-one package, you
> still have to maintain that system too...

Ah, but with an all-in-one package you don't have to maintain the code
that glues it all together.  Either way there has to be a librarian
which maintains the server/repository, but maintenance on those glue
scripts is an entirely separate, and large, issue to tackle.

> > I will agree that incompatibility with the environment around you is a
> > Bad Thing.  But the cost of 'gluing' CVS together with other things is
> > prohibitive.  And the training costs of CVS are equally prohibitive.
> > Many people who would like to use an Open Source version control tool
> > come from the non UNIX mindset, and will have difficulty because, as you
> > say, they are 'effectively going against the grain'.  For die-hard UNIX
> > people this isn't such a bad thing.  But for the rest of the world...
> >
> 
> It's not that cut-and-dry. People that have no clue what 'version
> control' means will have enough trouble grokking that concept, let alone
> using a given VC system or utility. Integration of any tool is going to
> cause some amount of ruckus, but that varies *greatly* on the existing
> setup and the people using it. In that sense, starting to use a VC tool
> like CVS is no different than switching compilers.
> 

I've seen people try to switch to CVS from other tools, and they tend to
stumble quite a bit.  The amount of ruckus also varies *greatly* on the
tool selected.  And I disagree with comparing VC to switching
compilers.  Comparing VC to switching languages perhaps.  Comparing VC
to switching IDEs perhaps.

-- David F.