22 Nov 2004 company   » (Master)

(updated, I was kind of in a hurry when I started writing it. And yes, I missed my bus.)

Since Colin and Havoc are into version control systems, I'll offer my thoughts, too. This is mainly what I realized when doing some of my code in arch (using tla) and some of it in CVS. It's also mostly evolutionary and doesn't try to go as far as Havoc's ideas.

  • Please honour the structure of my project and allow me to use it. In CVS I can commit, diff, update and whatnot from any directory, with tla I need to use the top source directory.
  • Don't clutter my working directory or invent other requirements. It is my working directory and I intend to work with it. This includes searching through it (tla puts lots of changesets or whatever into the .{arch} dir and these end up being duplicates in my searches). It includes moving the whole working directory elsewhere and continuing to work with it (tla caches inodes, so all hell breaks lose when I copy it to my laptop and try to do stuff from there). And it includes moving around files to better organize my source tree (not possible in CVS unless you move the files on the server).
  • Allow changing all user-readable identifiers easily. I named one of my first repos for testing arch "company@localhost". When I later wanted to publish it, I couldn't just rename it to something sensible like "otte@gnome.org". Now everyone can happily use "company@localhost" for a while.
  • Give me an easy way to work with a file's history. I'm currently doing this via ViewCVS mostly, but has the drawback in that it relies on the repository owner providing such an interface. While most projects do have such a history viewer, especially smaller ones don't. What am I using a history for? It's mostly 2 things:
    1. understanding where code comes from. Sometimes there are little if's or assertions that are neither obvious nor documented but easily understandable when you see when and why they were committed (especially the commit message helps.)
    2. monitoring changes between two different versions of a file. This can either be between two timestamps ("X stopped working, who's fault is that?") or between two branches ("Why does it work so much nicer over there?")
    It would be nice if what ViewCVS can do were possible with an application on my local machine, ideally between different archives (my local arch branch of the main CVS repo or whatever).
  • Don't invent your own $X when there's already a solution that's accepted out in the wild. This especially strikes me with arch's ChangeLog handling. I like the ChangeLogs in GNOME, don't screw me with those weird other ChangeLog method. It produces badly readable files. (see Rhythmbox's ChangeLog)
  • It'd be nice if I could browse different projects without the need to download the repositories first. "Look at how KDE does it" is not that rare. Sure, I can use VIewCVS - if it's there.
  • Another feature that I often miss is undo for every operation I do to my repository. Treat my repository like a Gimp image, spreadsheet or something, and have an undo button just like they do. So I can get my accidently deleted files back, undo the stuff I worked on for two days that doesn't work and whatnot. Shouldn't even be that hard to implement once inotify has hit the roads.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!