Version control

Oh, I've certainly never seen anyone use, well in fact, never seen a GUI for RCS... But then RCS was probably one of the first source control things (SCCS? Endevor?) there were... In fact, I've not used a command line for a source control system since RCS (except for writing automated build processes and so on).

Track changes is MENTAL.

Anyone look at SVK which is an improved svn for essentially giving you a local repository that doesn't need net access to perform commits and such.

There are so many things wrong with CVS. Keith should be drawn and quartered.

Anyone use Trac? Its like svn gui + tickets + wiki. Nice.

There are so many things wrong with CVS. Keith should be drawn and quartered.

Eh? I didn't say I like CVS. I don't! I hate it!

RCS is quite handy for versioning config file changes. You can quickly check what was just changed, and if the new config is broken, roll back to the previous version. Configs don't have to fill up with ugly comment lines disabling old stuff and actual commentary can be kept in the metadata.

The virtue of the command line isn't just the zen factor, in my estimation. It's the programmability. Or at least, the simplicity of programmability, given the relative nightmare that is GUI scripting. I use Perforce at work, which has graphical and command interfaces; the latter of these is absolutely vital for our build distribution system.

I don't have anything against the Perforce GUI, P4V, in principle, but it's built on some obviously-optimized-for-Windows "cross-platform" toolkit that's Carbontastically assy on Mac and the whole thing just slows me down. Judicious use of cdpath and open -a vim work much more smoothly for me.

Programmability - absolutely... Couldn't agree more. I'm sure you know what I mean, though... The type of people who claim that vi + gcc is the most productive programming environment there is, but it's really just designed to impress managers, or people who don't know what they're doing. To people who don't know about it, the more it looks like a computer is portrayed in films (i.e. green screens etc.) the more impressive it is, because most people are used to GUIs, and people are brought up to believe that green screens/text input is 'real' - that you must really know what's going on.

For me, every tool ought to have a well thought through command line interface or API as much as it has a GUI and it'll suddenly become useful in many more situations.

As you say, for source control systems, a command line is basically vital - no-one would use one if it didn't have one because you need to integrate it into your build process.

I wouldn't say that the command line is any more "real" than the GUI, certainly, for programming or anything else. Non-GUI debugging is, at least for me, an order of magnitude less productive than command-interface debugging, for instance. I recently ported an ASP app to Sun ASP, and not only had I no graphical debugger, but I had NO debugger at all. Furthermore, the Sun ASP engine usually didn't log the correct line number when it caught an error, preferring a number 10 or 20 greater than that. This is when the engine wasn't dying from SIGSEGVs arising from its inability to correctly unwind the stack. That was one of the more difficult debugging tasks I've encountered.

Contrast that with debugging servlets with NetBeans: Included is an instance of Tomcat set up for remote debugging, so it's absolutely trivial to get started and pop in a dynamic breakpoint or two and get an idea of what's going on by mouse-hovering over a few variables in the source. That's a helluva lot faster than peppering the code with printlns. My only real issue with NetBeans is that there's no vi-mode.

> My only real issue with NetBeans is that there's no vi-mode.

http://externaleditor.netbeans.org/