[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvswrappers - any better suggestions ?

From: David H. Thornley
Subject: Re: cvswrappers - any better suggestions ?
Date: Tue, 03 Apr 2001 09:48:39 -0500

"Greg A. Woods" wrote:
> [ On Monday, April 2, 2001 at 09:56:28 (-0500), David H. Thornley wrote: ]
> > Subject: Re: cvswrappers - any better suggestions ?
> >
> > Philosophically, this seems to be a Platonist approach to
> > software tools, and you're in a community of Aristotelians.
> No, you Aristotelians are invading a community where you don't belong.
Y'know, it can be really difficult to figure out whether you're
surrounded by Platonists or Aristotelians.  

> Funny, but around here the paint cans come with their own opening tool

They do?  I've always used the screwdrivers.  (Am I buying my
paint in the right places?)

> Indeed the reason there are people prying versions of binary files out
> of their CVS repositories is because people generally do just choose to
> use the first thing that drops into the palms of their hands instead of
> taking the time to find the right tool for the job.  Unfortunately in
> the more virtual world of software engineering people are incredibly bad
> at making even roughly correct estimates in how much time they might
> save, or how much more productive they might be, by choosing the first
> tool that appears in front of them instead of doing a proper analysis
> and searching for the right tool.
Here's the situation I'm looking at.

We do most of our work in conventional programming languages like
C++ and Java and Perl, and these work very well with CVS. We use
HTML for some documentation, and that generally works well
(although I have little experience with CVS storing the abominations
you get when saving as HTML from Word).  We have things like
release branches and patch branches.  What this means is that
CVS works very well for most of the stuff we do.

On the other hand, there is stuff mixed in there that is not
source code.  One example would be image files for the HTML.
These files are most conveniently located in the same directory
as the HTML files, and in some cases source files.

This means that we have three choices.

1.  Continue to use CVS, accepting the problems with binary files.
2.  Use a combination of CVS and some other system that handles
binary files better.
3.  Switch to another tool entirely.

Realistically, (2) isn't going to fly.  CVS and the other system would
have to be too closely intertwined, and nobody wants to learn another
SCM system.  This leaves (1) and (3).

The problem with (3) is that CVS is very good for most of what we
do.  We need things like branches and concurrent development, and
the fact that it has been working for a long time with few
problems.  Our source code is the company's most valuable asset
(not counting people).  Reliability and confidence are good things
for this.  If we were to go to another system, we would not have
the same trusting feeling, and would go through a learning curve.

I'm not saying we're going to use CVS forever, but any replacement
needs to have much the same features as CVS or productivity is going
to take a real hit.

So, if somebody can point to a SCM system that has the same reliable
reputation, doesn't cost too much, and does the same sorts of things,
I'm listening.  Otherwise, in a world where none of the tools
exactly match my needs, I'm going with what seems to me the best
choice, and right now that's CVS.

David H. Thornley                          Software Engineer
at CES International, Inc.:  address@hidden or (763)-694-2556
at home: (612)-623-0552 or address@hidden or

reply via email to

[Prev in Thread] Current Thread [Next in Thread]