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

[Tom Lord]

    > From: Zenaan Harkness <address@hidden>

    > This sounds like an argument for tla vs bitkeeper, which is not
    > what I was saying in the slightest. Unless the argument is that
    > the time period during which a commit is occurring would be too
    > onerous to lock "get"s out of - I'd find that hard to believe
    > though - and if it really were a problem, of course, the
    > existing behaviour is there.

It sounds as if, in general, you are asking for locks at a higher
level of the process.

As an example: suppose we automagically create a branch for the
purpose of "fixing Bugzilla issue #1234".

One might want to allow a developer to lock that branch -- to claim
the exclusive right to work on it.   Similarly, when that branch is
done, one might want to lock the "mainline" while that fix is being
merged into the mainline (even if it might take N hrs/days to test the
merge before committing).

Nothing in the transactional logic of development lines and revisions
requires such locking and so, no, arch does not go out of its way to
provide it.   Nor should it --- at core, arch is capturing a pretty
general and natural transactional semantics that "just happens" to map
nicely onto software development.

At the same time, yes, higher-level tools can provide such things.
The main way that arch helps prepare the way for such tools is with
its well-defined namespace: at least you have names for things you
might want to "lock".  Another important way that arch helps (and a
way that can be enhanced beyond its current state) is with its locking
facilities for development lines.  Those low-level elements provide a
portion of a good foundation for higher-level "process oriented
locking".

Ironically: CVS was initially considered so cool (by some, and icky,
by others) precisely because it threw away "process oriented locking"
and provided only the lowest levels of (logically necessary, for RCS'
transaction semantics) locking.

-t