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

[Zenaan Harkness]

>     > 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.

Are there any examples of such an existing 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).

Ah, good - that clears a misconception of mine.

> Commits to different development lines that happen to live in the same
> archive

Of course, that makes good sense. I don't think I'd argue against that.

>  and txns such as `make-branch' are not serialized.

What does this mean - "make-branch is not serialized", and what are the
consequences? (I'm guessing perhaps not serialized with respect to
commits.)

>  I suppose
> that they *could* be but this would simplify exactly none of the code

I would expect locking to introduce complexity - this is about
simplifying the user experience/ api, not about reducing code
complexity.

> and would eliminate a perfectly reasonable capability.

I don't understand the "make branch is not serialized" so I don't
understand what such non-serialization buys.

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

Which affests what parts of the archive - adds patches in a version
(which obviously must not be corrupting the archive, or things would
go whacky pretty quick), or modifies different versions/ branches/
categories (which sounds to me effectively like modifying different
trees, therefore also no problems).

I have been under the assumption, based on comments on gau, that
there were potential conflict problems that one needed to be aware
of, that potentially could be solved by introducing some locking
(and yes, more code complexity).

All said, as long as I can "tla get" some tree version, and
I get a transactionally consistent view, then how you implement
that would not concern me, and I'd be raising non-existent issues.

tia
zen