gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Zenaan Harkness
Subject: Re: [Gnu-arch-users] .listing files
Date: Thu, 23 Sep 2004 06:23:07 +1000

On Thu, 2004-09-23 at 00:54, David Allouche wrote:
> On Tue, 2004-09-21 at 18:35 -0400, James Blackwell wrote:
> > Tom Lord:
> > > I wouldn't refer to the documentation there, yet, until the docs
> > > include a passage to be specifically referenced.
> > >
> > > Perhaps simply something like:
> > >
> > >      Be aware that .listing files created by arch are a convenience
> > >      feature for use with simple HTTP setups.   Because of limitations
> > >      in how they can be implemented, users of .listing files may need
> > >      to run the `archive-fixup' command from time to time and
> > >      administrators of mission-critical systems should understand 
> > >      the security and robustness issues of using them.
> > 
> > The -l option is required for archives accessed by HTTP. Using other 
> > supported transfer methods (e.g. WebDAV or sftp) is recommended 
> > over using -l
> 
> 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. Using the `archive-fixup' command may be
> needed to regenerate the listings if they were corrupted by concurrent
> archive modifications.
> 
> I think the message should be scary.

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?

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 :)

tia
zenaan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]