Uncategorised

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 only working against a subtree in CVS and Subversion. In all three systems, you can request diffs for individual files by passing the filenames as additional arguments. Unfortunately baz requires you to pass “--” as an argument before the filenames, but hopefully that’ll get fixed in the future.

When it is time to commit the change, all three systems use the commit sub-command. This command also works on a full tree with Arch.

Branching and Merging

Creating a branch is relatively easy in all three systems:

cvs tag foo-anchor . ; cvs tag -b foo .
svn cp . svn+ssh://user@host/svnroot/modulename/branches/foo
baz branch modulename--foo--0

Unlike CVS and Subversion, the baz command will also switch the working copy over to the new branch. By default it will create a branch in the same repository, but can just as easily create a branch in another location.

To switch a working copy between branches, the following commands are used:

cvs update -r foo
svn switch svn+ssh://user@host/svnroot/modulename/branches/foo
baz switch modulename--foo--0

If we switch the working copy back to the trunk, we can merge the changes from the branch you’d do the following:

cvs tag -r foo foo-DATE .; cvs update -j foo-anchor -j foo-DATE .
svn merge -r branch-rev:HEAD svn+ssh://user@host/svnroot/modulename/branches/foo
baz merge modulename--foo--0

This is where Arch’s history sensitive merging starts to shine. Since the working copy retains a record of what changes it is composed of, the merge operation simply pulls over the changes that exist in the branch but not in the working copy — there is no need to tell it what range of changes you want to apply.

To merge more changes from the branch, the CVS and Subversion commands change, while the Arch one remains constant:

cvs tag -r foo foo-DATE .; cvs update -j foo-LAST-DATE -j foo-DATE .
svn merge -r last-merge-rev:HEAD svn+ssh://user@host/svnroot/modulename/branches/foo
baz merge modulename--foo--0

Conclusion

The current Bazaar command line interface isn’t that different from CVS and Subversion (it’s definitely worth a second look if tla scared you off). The main difference is that some of the operations work on the whole working copy rather than a subset by default. In practice, this doesn’t seem to be much of a problem.

The history sensitive merge capabilities would probably be quite useful for Gnome. For example, it would make it trivial to merge bug fixes made on the stable branch to the head branch.

Disconnected development is a natural extension to the branching and merging support mentioned earlier. The main difference is that you’d have to make a local archive, and then create your branch of the code in that archive instead of the main one. The rest is handled the same.

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:

  1. In 1984, Vivian moved to Australia to live with her new husband.
  2. 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”.
  3. On July 17, 2001, the Queensland Department of Families finally notified police that “Vivian Young” was missing.
  4. 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.
  5. 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.
  6. 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.

29 April 2005

Ubuntu Down Under

I have been in Sydney for the past week for UDU, which wraps up tomorrow. It has been great meeting up with everyone again, but has also been exhausting.

Some of the stuff on the horizon will be quite ground breaking. For instance, I don’t think anyone has attempted something like Grumpy Groundhog (which will hopefully be very useful to both the distro team, and upstream projects like Gnome).

Python

Experimented with using the new ELF visibility attribute support in GCC 4 in Python, and came up with this patch. It restricts the list of exported symbols to just the ones marked with the PyAPI_FUNC and PyAPI_DATA markers, which omits all the private symbols that /usr/bin/python or libpythonX.Y.so export.

In addition, it uses “protected” visibility for all the exported symbols, which means that internal calls to the public Python API don’t have to go through the PLT (which they do if Python is compiled as a shared library).

In the shared libpython case, this speeds things up by about 5% (according to pystone and parrotbench), which isn’t too bad for a small patch. In the static libpython case, it seems to slow things down slightly — by < 1% in my tests so far.

Of course, the shared libpython case is still slower than the static version (which is why /usr/bin/python doesn’t use a shared libpython on Ubuntu), but it does make it less slow than it was before 🙂

Solaris

Glynn: If Solaris feels like a second class citizen, it is probably because hardly any hackers have access to Solaris machines (the same seems to be true of architectures other than i386). A fair number of developers would probably be interested in fixing Solaris build failures if they knew that they existed.

I realise that Sun doesn’t want to provide external access to a build machine (at least, that’s what I was told last time I asked some Sun/Gnome hackers), but maybe running a tinderbox style system and publishing the build logs would help. As well as telling me if my package is broken, it’d give me a way to tell whether the fixes I check in actually solve the problem.

pkg-config

One of the changes in the recent pkg-config releases is that the
--libs output no longer prints out the entire list of
libraries expanded from the requested set of packages. As an example,
here is the output of pkg-config --libs gtk+-2.0 with version
0.15:

-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0

And with 0.17.1:

-lgtk-x11-2.0

If an application is compiled with the first set of -l
flags, it will include DT_NEEDED tag for each of those
libraries. With the second set, it will only have a
DT_NEEDED tag for libgtk-x11-2.0.so.0. When run,
the application will still pull in all the other libraries via shared
library dependencies.

The rationale for this change seems to boil down to:

  • Some programs link to more libraries than they need to.
  • Sometimes programs link to libraries that they don’t use directly
    — they’re encapsulated by some other library they use.

  • The application will need to be recompiled if one of the libraries
    it is linked against breaks ABI, even if the library is not used
    directly.

At first this seems sensible. However, in a lot of cases
applications actually use libraries that are only pulled in through
dependencies. For instance, almost every GTK application is going to
be using some glib APIs as well.

With the new pkg-config output, the fact that the application
depends on the ABI of “libglib-2.0.so.0” is no longer
recorded. The application is making use of those APIs, so it declare
that. Without the glib DT_NEEDED tag, the application is
relying on the fact that GTK isn’t likely to stop depending on glib
…

Furthermore, this causes breakage if you link your application with
the libtool
-no-undefined flag. On platforms that support it, this
generates an error if you don’t list all the libraries the application
depends on. This allows for some optimisations on some platforms
(e.g. Solaris), and is required on others (e.g. Win32).

(interestingly, this problem doesn’t exhibit itself on Linux.
The -no-undefined flag expands to nothing, even though the
linker supports the feature through the -zdefs flag)

For these reasons, I’ve disabled the feature in jhbuild’s
bootstrap, using the --enable-indirect-deps configure flag.
If the aim is just to get rid of unnecessary library dependencies, the
GNU linker’s --as-needed flag seems to be a better choice.
It will omit a DT_NEEDED tag if none of the symbols from the
library are used by the application.

The Colour Purple

If you look at the bottom of Cadbury’s website in the footer of the page, you find the following text:

…, and the colour purple are Cadbury Group trade marks in Australia.

Apparently Cadbury believes they can trade mark a colour, and according to a story on the radio they’ve been sending out cease and desist letters to other small chocolate makers in Australia.

It turns out that even though they are claiming it as a trade mark, they only have a pending application. The details can be found by going to here, choose “enter as guest”, and enter “902086” into the search box at the bottom (it doesn’t seem like you can bookmark a particular application).

It seems that the application has been pending since February 2002, and was deferred at the applicant’s request 5 months later. So it seems weird that they’ve started trying to assert it now. The 17 categories the application mentions include soaps and perfumes, jewellery, kitchen utensils, clothing and leathergoods (it also includes classes that you’d expect a chocolate company to claim).

It seems like a clear abuse of the trade mark system, and I’m surprised it isn’t getting more news coverage.