Version control

Version control makes so much sense for documentation - I'm keeping my user manual document versioned as well as a functional specification. So much easier to come back after a long weekend and run a diff to see where I left off than using @$#%&%$ track changes in MS Word.

x-post

Hmm... Not sure that's really targetted at the same thing... In my understanding, it's just about plucking things you used to have back into the current time, i.e. never delete anything. Branching and merging is not really part of the picture, is it... But it's quite shiny.

Absolutely, they've just envisioned it as a backup thing. But if you compare all the previous backup clients to it (uhhh god yuck), I'm thinking there's a not-dissimilar thing could be done with version control. Probably not for coders -- that stuff would be insanely irritating -- but for people bashing out documents. I VC all my essays and articles, and it's v. handy for when you've gone down the wrong track, or branch out something interesting for later and so on. It'd be good if everyone could get that.

Word's track changes is hilariously bad, actually.

To be fair to Word, my ex-colleague did his PhD in diffs, and it's a non-trivial process that has many solutions but with no way to define the optimal solution.

Fair to Word? BAN KEITH

Yeh, it's hard to define the optimal solution, but highlighting unchanged text probably isn't even near to it

From a track changes FAQ:
Q: How does Word choose which colour to allocate to which author?

In theory, Word allocates colours to reviewers in the following order: red, blue, green, violet, dark red, teal, dark yellow and grey. For the 9th and subsequent reviewers of a document, Word cycles through the colours again. But in practice, as reviewers come and go (as their revisions are accepted or rejected), the allocation of colours to reviewers ends up, in effect, random.

If I can't be teal, I'm not playing.

Part of my job at the last place was generating and maintaining a ginormous user manual where every revision got commented on by 14 different people. They wouldn't circulate the doc; each one had to change their own copy and I got to "merge" it all together as the originator of the document. Horrendous.

Thinking back on this, vc wouldn't have helped me with that lot, since I couldn't even get them to round-robin the doc. It would have been a hand-holding tech support nightmare to get them to use vc. And, there's always that one guy who won't mod the doc electronically, but has to print it out and mark it up w/crayons.

Yeah, I wouldn't want to be associated with anti-GUI ludditism. I'm a Mac user for GUI/aesthetic reasons, and switched around the first Public Beta (I do need _a_ command line!)

My personal top tip for version control is Mercurial. Depends on Python, but it's distributed (unlike SVN/CVS, which require a server, and like git) ultra-lightweight and not inherently broken (unlike darcs). I'm using it for all my own projects, and thinking of trying it out with a couple of collaborations and my thesis. If I was honest, I think part of my attraction to it is that it's written in Python, which I am totally down with, but has no practical consequences for the user. However, I am not the only one who likes it: Mozilla (not Firefox) was a big recent capture.

http://www.selenic.com/mercurial/wiki/

My understanding of git is that it tries to replicate various BitKeeper features that Linus found useful managing a preposterously big collaboration, in a purely Free Software code. It and mercurial are apparently quite similar philosophically and architecturally, but mercurial is rather more lightweight, I _think_.

Also, the fact that I've never seen anyone use a GUI for RCS is probably because I've always been in academia, where Microsoft is a non-issue, and no one writes GUIs themselves.

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/