Re: [Gnu-arch-users] .listing files

[Tom Lord]

   [topic of .listing generally]

We should be careful to distinguish the way clients *read* .listing
files from the way tla itself will *write* them: reading them is just
fine;  creating them is something tla can do but as has been noted
(e.g., w/cgi scripts) it is not the only way they can be created.


    [someone:]

    >> The --listing option is required for archives accessed by
    >> HTTP. Using other supported transfer methods (e.g. WebDAV or
    >> sftp) is recommended.  HTTP access is supported thanks to
    >> directory listings stored in ".listing" files, however the
    >> implementation is not robust for concurrent modifications.

That ("for concurrent modifications") is not an accurate summary of
the issues.

    >> Using the `archive-fixup' command may be needed to regenerate
    >> the listings if they were corrupted by concurrent archive
    >> modifications.

And so that would be a misleading instruction.


    >> I think the message should be scary.

Yes, but not inaccurate and misleading.

I am not saying it is easy to make a concise, high-level, accurate,
and informative summary of the issues -- I don't think it is -- but
that is a reason to be less specific, not less accurate.

A low level description can be accurate, specific, and informative,
but only the most experienced users will understand its import.

So a simple "get a clue before using this in a mission critical
system" seems about right to me, even without any additional clue
about what specific "clue" is needed.


    > I've raised this before in a not so direct way:

    > In Aegis, when you "integrate", a 'lock' is taken when the
    > "aeib" (aegis integrate begin) command is run (file "=lock" or
    > whatever), to serialize commits.

    > Is it possible to 'easily' add such functionality to arch?

    > Or is it better to somehow layer something on top of arch?

It is a site-specific thing.  In some set-ups, that can be done and in
others, not so much.  One approach to layering it would be to
establish a policy for using the existing `lock-revision' facility.


    > This parallel committing is kinda funky, but seems unnecessary
    > in the general case (think bitkeeper, linux kernel, 10MB patches
    > per month, all serialized, yadda yadda).

    > Really, is anything gained by allowing these parallel commits
    > other than bragging rights? (OK, flame me down on that one - but
    > I really do want to know, so please do include an explanation
    > with your flame :)


Commits within a single development line in arch *are* serialized
(and, indeed, it would be meaningless for it to be otherwise).

Commits to different development lines that happen to live in the same
archive and txns such as `make-branch' are not serialized.   I suppose
that they *could* be but this would simplify exactly none of the code
and would eliminate a perfectly reasonable capability.

I'm sure I've done concurrent commits to a single archive just because
it was convenient to do so.


-t