"Eric Niebler" <eric@boost-consulting.com> 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