[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] .listing files
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] .listing files |
Date: |
Wed, 22 Sep 2004 13:55:14 -0700 (PDT) |
[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
- Re: [Gnu-arch-users] .listing files, (continued)
- Re: [Gnu-arch-users] .listing files, David Allouche, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Zenaan Harkness, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Aaron Bentley, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Tom Lord, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Zenaan Harkness, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Aaron Bentley, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Tom Lord, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Zenaan Harkness, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Andrew Suffield, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Tom Lord, 2004/09/22
- Re: [Gnu-arch-users] .listing files,
Tom Lord <=
- Re: [Gnu-arch-users] .listing files, Zenaan Harkness, 2004/09/22
- Re: [Gnu-arch-users] .listing files, Tom Lord, 2004/09/22
- Re: [Gnu-arch-users] .listing files, James Blackwell, 2004/09/23
- Re: [Gnu-arch-users] .listing files, Harald Meland, 2004/09/23