Accidental update of gnulib version?

[Jordi Gutiérrez Hermoso]

Rik,

In 14001:5f0bb45e615c, you updated the gnulib version, from ff549c078
to bb052d4a7. Was this intentional? Your commit message doesn't
mention it. It's probably ok, but I think we should be conservative
about updating gnulib and only do so to fix evident problems.

If you update your version of gnulib, you can do

    hg commit -X gnulib

to exclude the gnulib directory from the commit.

If the problem is about having lots of local clones and not wanting to
clone gnulib remotely too, there are also some fixes for that
situation. There's a definitive fix for that, it's only available in
newest hg versions (2.0 and later). It's basically this:

    http://mercurial.selenic.com/wiki/SubrepoRemappingPlan

In 1.8, there are some workarounds which involve first cloning the
gnulib subrepo and then updating the octave repo. What you can do is

    ## Clone but don't attempt to update
    hg clone -U some-local-octav-repo another-octave-local-repo

    ## Clone gnulib locally
    cd another-octave-local-repo
    git clone some-local-gnulib-clone gnulib

    ## Now update, including updating the gnulib repo to whatever
    ## appropriate revision
    hg up

Sorry for the inconvenience, but I think it's far better to version
the gnulib subrepo along with the Octave so that we can better
diagnose problems and avoid them.

- Jordi G. H.