Laurence’s Blog

I quite like trac and use it for “managing” (for well defined values of managing) the various projects I work on (I’m currently using subversion for version control and so trac makes logical sense as it was designed to work with subversion, although other version control backends are now supported).

Recently a former student at Warwick, Peter Ellis, gave an interesting talk on managing projects based upon his experience working in industry. During his talk he alluded to liking the bazaar revision control system. Bazaar is a distributed system, as opposed to subversion and the older cvs systems which rely on a central repository.

Personally I could not see the advantage of distributed versioning over centralised and could not get my head past the idea the distributed versioning would result in a horrendous mess of different version distributed all over the place which were completely out of sync.

Seeking further enlightenment, I spoke to some of my peers at Warwick who were using a distributed versioning system for the project they were working on. They pointed out that as the version control is distributed every checkout is in effect also a repository. This allows the same work flow to occur offline as online with all of the changes to the repositoy pushed upstream when it is more convinient (i.e. an internet connecting is available). As a result many changesets can be applied to the local repository, which is desirable when multiple major alterations are being made to a project. With subversion this would not be possible without a connection to the central server due to its concept of a single ‘Working copy’ when offline.

The only downside I see to switching to bazaar (or a similer versioning system) is that my use of trac’s bug tracking/milestone management and wiki, negate the benefits as I have to have an internet connection to use them. While I could live without the Wiki as I can just store text files inside the repository with the same contents (in fact the wiki was initially populated from text files containing various ideas I’d had, when I started using trac) I cannot do without the bug tracking and milestone management.

Looking around on the internet I found a couple of promising looking bug tracking systems designed to be used with distributed revision control systems, such as Bugs Everywhere and artifacts. Tracker for ruby also looked quite nice, until I realised it was using SQLlite which, although it stores its data in a single file on the filesystem, uses a binary format which is unlikely to place nice with most (if not all) versioning systems. Both Bugs Everywhere and artifacts are written in Python. I was unable to get Bugs Everywhere to run under Windows, and artifacts seems to run but spaffs out a lot of warnings if not being run within a darcs repository.

As a result I am sorely tempted to write my own bug/milestone tracking system in Perl (using only standard libraries, nothing from cpan, so it should just-work™ on most systems with Perl out-of-the-box™). The obvious criteria (besides just-working™) being a text-based storage method such that adding/removing & updateing bugs is easilly diff-able (for the revision control system), completely usable offline, allowing the grouping of bugs for milestones and reasonably attractive to use (whilst being command-line driven and avoiding the use of ncurses for the purpose of compatiblity, see below). Ideally the fields (priority/summary/milestone etc) would not be pre-defined so the user can create what is needed depending on the project (e.g. in an personal project ‘assigned to’ would be completely redundant as there is only one developer, me).

Whilst it would be nice to use BASH(and associated “standard” unix utilities) to write this, I think this would be a bad idea for two reasons 1. It does not solve the not working on Windows problem (I’m completely side-stepping cygwin here on the grounds that my laptop, which is my primary development machine, has ActivePerl installed for my third year project, but not cygwin under Windows) and 2. I can forsee this getting quite complex should I wish to add more nifty features (a stand-alone webserver for a web-interface would be nifty(if somewhat excessive!), for example) as which point BASH may prove insufficient and the project ends up depending on BASH and Perl whereas I might as well have chosen Perl in the first place and only have one dependancy.

Of course, even starting this project depends on me getting sufficiently far ahead with my third year project to set aside a day or two to write most of the code. The whole idea may end up on my stack of nifty projects that never get properly started, along with all the other projects I’ve been shelving there since my GCSE days.

On the topic of project management, I work Saturday mornings at Startin Tractors and often come home feeling that I’ve worked solidly for 5 hours and achieved nothing. This morning I made an effort to ensure I worked away at the bug list for the system I wrote and closed the tickets as I fixed them. As a result I returned home having commited 9 changes to subversion (as I avoid commiting broken code, on principle, this suggested that 9 problems were fixed), closed 4 tickets (however some items are, of course, considered to minor to ticket, like changing the wording of a dialogue) and opened 5 new tickets. Although a net increase in open tickets I came away felling I had accumplished a lot in the time due to the amount of activity showing up in the trac timeline.

Incidentally, looking at the timeline I can determine exactly what I was doing at any given point of the morning. I can tell, for instance, that the first fourty minutes of the day were spent fixing a bug in the “latest arrivals” facility whilst the last hour was spent (desperately!) fixing a critical bug in the caching system which caused the entire edit feature to die horribly whenever a change was made to an existing piece of machinery.