Monthly Archives: May 2005

SCM Command Line Interface Comparison

With the current discussion on gnome-hackers about whether to switch Gnome over to Subversion, it has been brought up a number of times that people can switch from CVS to Subversion without thinking about it (the implication being that this is not true for Arch). Given the improvements in Bazaar, it isn't clear that Subversion is the only system that can claim this benefit. For the sake of comparison, I'm considering the case of a shared repository accessed by multiple developers over SSH. While this doesn't exploit all the benefits of Arch, it gives a better comparison of the usability of the different tools. Setup Before using any of CVS, Subversion or Arch, you'll need a repository. This can be done with the following commands (run on the repository server): cvs init /cvsroot svnadmin create --fs-type=fsfs /svnroot baz make-archive --signed arch@example.org /archives/arch@example.org (the --signed flag can be omitted if you don't want to cryptographically sign change sets) Once the archive is created, you'd need to make sure that everyone has write access to the files, and new files will be created with the appropriate group ownership. This procedure is the same for each system. Now before users of the arch archive can start using the archive, they will need to tell baz what user ID to associate. Each user only needs to do this once. The email address used should match that on your PGP key, if you're using a signed archive. baz my-id "Joe User <joe@example.com>" Next you'll want to import some code into the repository. This will be done from one of the client machines, from the source directory: cvs -d :ext:user@hostname:/cvsroot import modulename vendor-tag release-tag svn import . svn+ssh://user@hostname/svnroot/modulename/trunk baz import -a sftp://user@hostname/archives/arch@example.org/modulename--devel--0 In the subversion case, we're using the standard convention of putting the main branch in a trunk/ subdirectory. In the arch case, you need a three-level module name, so I picked a fairly generic one. Working with the repository The first thing a user will want to do is to create a working copy of the module: cvs -d :ext:user@hostname:/cvsroot get modulename svn checkout svn+ssh://user@hostname/svnroot/modulename/trunk modulename baz get sftp://user@hostname/archives/arch@example.org/modulename--devel--0 modulename The user can then make changes to the working copy, adding new files with the add sub-command, and removing files with rm sub-command. For Subversion there are also mv and cp sub-commands. For Arch, the mv sub-command is supported. To bring the working copy up to date with the repository, all three systems use the update sub-command. The main difference is that CVS and Subversion will only update the current directory and below, while Arch will update the entire working copy. If there are any conflicts during the update, you'll get standard three-way merge conflict markers in all three systems. Unlike CVS, both Subversion and Arch require you to mark each conflict resolved using the resolved sub-command. To see what changes you have in your working copy, all three systems support a diff command. Again, this works on the full tree in Arch, while…

Something is wrong with the Immigration Department

Shortly after the scandal over Cornelia Rau (a mentally ill Australian who was in detention for 10 months), another case gets some media attention: Vivian Young/Alvarez/Solon. She is an Australian citizen born in the Phillipines, who also suffers from a mental illness. From the news reports, the sequence of events seems to be: In 1984, Vivian moved to Australia to live with her new husband. In 2001, she was involved in a car accident in NSW. While being treated at Lismore Hospital for her injuries, she lodged a citizenship application and the staff contacted the immigration officials. She gave her name as "Vivian Alvarez". On July 17, 2001, the Queensland Department of Families finally notified police that "Vivian Young" was missing. Days later, she was deported to the Phillipines -- neither the NSW or Qld police noticing that she was on the missing persons list. Apparently she was pushed onto the plane in a wheelchair, still suffering from head injuries. In 2003, an immigration official discovered the mistake while looking through the missing persons list. It doesn't seem that any action was taken at this time. This month, the mistaken deportation becomes public. This is the first time that the family is notified -- four years after the deportation, and two years after the mistake had been discovered. The government says they don't know her location, but are doing everything in their power to find her. Among the Australian family, she left behind a son who is still in foster care. Rather than being an isolated case, it is quite likely that there have been other questionable deportations -- this one getting more attention because the person in question is an Australian. This case has racial overtones too, since it is unlikely that a white Australian would have been deported under the same circumstances. Despite all this, the Minister for Immigration does not feel that a Royal Commission would be appropriate.

<tt>bgchannel://</tt> Considered Harmful?

  • Post author:
  • Post category:Uncategorized

Recently Bryan posted about background channels -- a system for automatic updating desktop wallpaper. One of the features of the design is a new URI scheme based on the same ideas as webcal://, which I think is a bad idea (as dobey has also pointed out). The usual reasoning for creating a URI scheme like this go something like this: You want to be able to perform some action when a link in a web page is clicked. The action requires that you know the URI of the link (usually to allow contacting the original server again). When the web browser activates a helper application bound to a MIME type, you just get the path to a saved copy of the resource, which doesn't satisfy (2). Helper applications for URI types get passed the full URI. So the solution taken with Apple's iCal and Bryan's background channels is to strip the http: off the start of resource's URI, and replace it with a custom scheme name. This works pretty well for the general case, but causes problems for a few simple use cases that'll probably turn out to be more common than you think: Serving a background channel (or calendar, or whatever) via a protocol other than http. The first alternative protocol you'll probably run into is https, but there may be other protocols you want to support in the future. Any links to a background channel will need to be fully qualified since they use a different scheme. If you move your site, you'll need to update every page that links to the background channel. If you could use relative URIs in the links, this wouldn't be the case. One alternative to the "new URI scheme" solution, that doesn't suffer from the above problems is to serve a "locator file" from the web server that contains the information needed to request the real information. Even though the helper application will only get the path of a temporary file, the content of the file lets the app connect to the server. This is the approach taken by BitTorrent, and various media players like RealPlayer. The separate "locator file" can even be omitted by placing the background channel location inside the background channel itself. This is the approach taken for Atom, via a <link rel="self"/> link.