Re: [boost] Release procedures

From: David Abrahams (dave_at_[hidden])
Date: 2006-06-27 12:40:59

"Eric Niebler" <eric_at_[hidden]> writes:

> I've never used TortoiseCVS, so I don't know. I use cvs and follow the 
> release procedures described at 
> http://boost.org/more/release_procedures.htm. I never merge more than 
> the files I'm working on.

I just want to reiterate something I've said here before.  I've seen
it repeatedly: people who pick up a GUI frontend for CVS (or for most
any other command-line tool) assuming it will make the tool easier to
understand often end up with an incomplete or erroneous understanding
of the tool, and they end up making crucial mistakes.  There are lots
of ways to explain this phenomenon: for one thing, the definitive
documentation of the tool is always written for the command-line, and
the GUI's documentation, in the interesting cases, usually refers to
it.  For another thing, the GUI's abstractions are almost invariably
incomplete.  At some level, the GUI always exposes the underlying
tool, so you have to learn it anyway.

And that doesn't even account for the reliability problems that one
normally sees in such frontends.  The problem IMO is that command-line
tools essentially have untyped interfaces.  There's usually some
relatively clean description of what inputs they accept, but their
outputs, which usually occur as text in two output streams, are much
less well-defined, particularly in the case of "error conditions."
When something goes wrong, the GUI often can't recognize it, or can't
report it, or can't report it in terms of the GUI's abstractions.

IMO this is one of the reasons that Linux has such a hard time
approaching real joe-nonhacker-friendliness.  The answer, of course,
is to have the command-line tools and the GUIs use libraries with
strongly-typed interfaces and well-defined exceptions.  But who has
time for that? :)

So, moral of the story: especially in cases where what you do with the
tool is going to affect other people (e.g. Boost), learn the
underlying command-line tool first.  Then if the GUI makes some things
easier, feel free to use it, with the full understanding of what's
really happening under the covers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com