[Gnu-arch-users] Issues with very large source base and spaces in file names

[Sakari Ailus]

Hello,

We're currently tracking a huge external source project (around 2,5 GB
compressed with gzip, 8 GB uncompressed, 400 000 files) with GNU Arch.

Tla is of Debian version 1.3-1, which I suppose is tla 1.3 with possibly
some patches. The machine is hyperthreading-enabled dual Pentium 4 Xeon with
2,5 GB ECC RAM and Linux 2.6.11.7.

GNU Arch has been working rather well although there are a few issues I've
noticed.

1. Support for file names with spaces.

Some files have spaces in their names. This is unusual, but as far as I
understood, it should work. While most operations work, some don't. Here's
an example of a file name with a space character in action. :) Luckily, no
important operations are hampered by this.

$ tla make-archive address@hidden /tmp/bar
$ tla my-id "Sakke <address@hidden>"
$ md baz
$ cd baz
$ tla archive-setup kaali--mainline--0
* creating category address@hidden/kaali
* creating branch address@hidden/kaali--mainline
* creating version address@hidden/kaali--mainline--0
$ tla init-tree kaali--mainline--0
$ touch bar
$ touch "bar 2"
$ tla add bar "bar 2"
$ tla import -s hihhei 
* imported address@hidden/kaali--mainline--0
$ tla file-find bar
./{arch}/++pristine-trees/unlocked/kaali/kaali--mainline/
kaali--mainline--0/address@hidden/kaali--mainline--0--base-0/./bar
$ tla file-find bar
illegally formed changeset index
(./{arch}/++pristine-trees/unlocked/kaali/kaali--mainline/
kaali--mainline--0/address@hidden/kaali--mainline--0--base-0/,,index)

(Oops...)

I.e. tla file-find fails after the first run. This applies to some other
command(s) as well AFAIR. Normal get/update/replay/commit/changes commands
still work fine.

2. Large changesets (or large whatever).

Although tla is not compiled with largefile support by default (nor in
Debian sarge currently), it seems to work fine as I did (read: had to do)
so.

There's one possible issue I've found: safe_lseek takes offset as long,
which is 32 bits wide on i386, unlike off_t, which is 64 bits. This should
not be a problem currently since all calls to safe_lseek set the offset to
0. :) But perhaps it's something to be aware of...

3. Occasional weirdness.

I've seen a few times something like this. vu_lstat seems to fail for a file
which Arch probably supposes to be there. Now I'm not sure whether this was
the earlier weirdness, but could be. It doesn't happen often, and running
tla again has helped so far.

$ tla update source--mainline--0
Error calling `vu_lstat' for "./a/b/c/d/e/f.tgz" (No such file or directory)
$ tla update source--mainline--0
Missing inode signature. Cannot verify reference tree integrity: you should 
remove and recreate this reference tree.
    tree:
/scratch/sailus/source/{arch}/++pristine-trees/unlocked/source/
source--mainline/source--mainline--0/
address@hidden/
source--mainline--0--patch-3
    archive: address@hidden
    revision: source--mainline--0--patch-3
* setting aside local changes temporarily
...

./a/b/c/d/e/f.tgz existed in old revision, but not in new one, which had
directories up to ./a/b/c/ still in place.

I don't know what causes this, is it Arch or Linux. I trust the machine
quite a lot since it's been behaving well otherwise.

-- 
Sakari Ailus
sakari dot ailus at saunalahti dot fi