[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unix philosophy under the gun?
Re: Unix philosophy under the gun?
Fri, 03 Aug 2001 14:51:24 -0400
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.
Re: Unix philosophy under the gun?, Greg A. Woods, 2001/08/03
RE: Unix philosophy under the gun?, Greg A. Woods, 2001/08/03