Version control

I think from the mainstream things (I dunno about non-mainstream things), that Subversion is the best thing I have used; in that, I trust it most. The biggest worry with source control is that it just doesn't perform the basic operations well 100% of the time. The initial subversion that I developed ILX on was shit, and transactions appeared to mess up half way through, leaving things in an inconsistent state. It was upgraded, though and once that was done it all worked fine.

I thought Caek's comment recently, of the nature that he had never seen a real developer using a GUI for source control was interesting. It's fairly common, but from my point of view, I'd never take anyone on who would claim they prefer command lines exclusively to GUIs (not exactly what Caek said, but it is a relatively common position that some people take). It's just so luddite and seems to pander to the fact that people think things are more 'real' when they're done on a green screen. To me, it's all about creating a big mistique around what one is doing. If you look closely, you see they're not really achieving very much, most often.

Agreed with that.

I don't use the command line subversion, though I guess I could. I've got TortoiseSVN and it's just so handy. All my work is done exclusively in Windows environments - I don't mind pinging and tracert'ing from the dark space, but I'd rather have that handy little right-click menu pop up for committing and updating and such.

We're also using Bugzilla for bug tracking - even the boss has bought completely into the web interface vs. sending out emails that seem always to get lost in the shuffle.

I don't mind pinging and tracert'ing from the dark space, but I'd rather have that handy little right-click menu pop up for committing and updating and such.

Me too... I mean, I have nothing against command lines and use them a lot, in all sorts of different environments: cmd.exe; bash; windows powershell; TSO/ISPF whatever. Powershell, in particular, is an amazing piece of kit, but in no way is (for example) GDB ever going to be more productive for degugging than say Eclipse.

Wiki on Git, btw. Sounds interesting.

My favourite command line was on MPW for the original Macintosh. You typed commands as expected, but if you couldn't remember the options for any command, you hit apple-enter and it popped up a dialog box with a gui for all the relevant settings. You "built" the command line by ticking boxes. Not nearly macho enough, tho.

It's a shame that version control doesn't have more pull outside of coding. If it did, we'd probably get better tools to use with it, instead of the clunky things we've got. When you do get version control in other apps, it's almost as if the developers haven't realised what they're making, and you're left with retarded implementations. We've been using Quark's QPS system at work for years, and it keeps a history of all the changes to every article. It's about 15 years old now, and in the latest version there's *still* no way to get a diff between two versions of a story. Gah.

Thanks for that.. I read about Torvalds' complaints about Bitkeeper a few years ago and was interested in how highly he praised its seeming ability to cope with all sorts of merging nasties (something that seems a bit intractible in my head). This is what I was thinking about upthread when talking about the less mainstream options...

x-post

Stet - as regards GUI stuff, the Subclipse stuff I use for ILX works just fine for me.

Yeh, there's lots of stuff out there -- there's apparently nice stuff for PC as well -- but you know me, I like the mac and all its shiny shiny. I mean, if I showed that to someone at work they'd weep.

Sure, but what about:

http://www.ilxor.com/scm.png

Or do you mean more shiny shiny than that?

Oh yeh, I'm thinking super shiny! Even the concept of a "base revision" is going to send them hurtling for the gin&tonix. :)

Time Machine is probably a step towards proper versioning for the peeps, except it has two horror drawbacks: no diffs, and doesn't look like there's any way to operate it except with the mouse, which would get tiresome pretty quick. And I don't know how you'd save a "revision" with it. Or collaborate. But it's a start.

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/