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.
― stet, Wednesday, 11 July 2007 23:33 (fifteen years ago) link
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.
― Jaq, Wednesday, 11 July 2007 23:45 (fifteen years ago) link
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.
― Jaq, Thursday, 12 July 2007 17:55 (fifteen years ago) link
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.
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_.
― caek, Thursday, 12 July 2007 19:43 (fifteen years ago) link
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.
― caek, Thursday, 12 July 2007 19:45 (fifteen years ago) link
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).
― Keith, Thursday, 12 July 2007 20:19 (fifteen years ago) link
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.
― Catsupppppppppppppp dude 茄蕃, Friday, 13 July 2007 15:38 (fifteen years ago) link
Eh? I didn't say I like CVS. I don't! I hate it!
― Keith, Saturday, 14 July 2007 18:08 (fifteen years ago) link
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.
― libcrypt, Sunday, 15 July 2007 12:08 (fifteen years ago) link
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.
― Keith, Sunday, 15 July 2007 12:32 (fifteen years ago) link
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.
― libcrypt, Sunday, 15 July 2007 13:15 (fifteen years ago) link
> My only real issue with NetBeans is that there's no vi-mode.
― koogs, Monday, 16 July 2007 12:18 (fifteen years ago) link