[darcs-users] Handling relative directories

[Petr Rockai]

Duncan Coutts <duncan.coutts at googlemail.com> writes:
>> Doing a good job of the library won't be a quick job, but it sounds worth 
>> doing if we can find someone willing :-) Any volunteers?
>
> Another possibility which uses somewhat less FFI would be to use a
> different representation of FilePath in darcs. I understand you already
> do use some different type.
>
> One option would be to use a representation like a reverse-order list of
> path components, with each component stored as a short packed string.
> That allows for sharing between paths and would reduce the cost of using
> long absolute paths.
>
> You'd still have a conversion via String to use the System.IO functions,
> but at least that's only temporary garbage so affects just CPU time not
> overall memory use.

Interesting idea. I have already started using a path type that is a
list of components (represented as bytestrings), it just did not occur
to me to make it reverse to improve sharing. I'll try to look into doing
that.

On the other hand, what we have now has very little overhead, since the
relative paths are stored packed, 0-terminated inside the index and we
call stat (by far the most time-critical file path use) with a pointer
into the mmap'd index. This is, unfortunately, not going to work with
absolute paths.

We can resolve this internally on POSIX-y systems by calling fstatat
instead of stat, presumably. On the other hand, this is POSIX.1-2008 and
it does not exist on, say, Linux 2.4 or older (or even early Linux
2.6). Means we need compatibility wrappers... either that, or disable
any threading support if these are not available.

It *might* actually be a reasonable compromise to only provide threading
on sensible systems (i.e. those that have openat/f*at...).

Yours,
   Petr.