Re: [Gnu-arch-users] [BUG] Race condition in changes

[David Allouche]

On Sat, May 29, 2004 at 07:32:54PM -0400, Aaron Bentley wrote:
> Robert Collins wrote:
> 
> >the working changeset should always have a unique name. If it's being
> >kept it should:
> >move an existing one out of the way.
> >move the working into the final position.
> >rm -rf the old one.
> 
> Why would we want such destructive behavior?  If the user selects a 
> filename, use that, but barf if something named that already exists.  If 
> it's an automatic filename, tla should pick one that doesn't already exist.

I think the behaviour suggested by Rob is more in line with the way of
Arch. I know that is a mystic argument, but my vision of software design
is quite impregnated with platonician mysticism. Without an explicit
changeset name, it is reasonable to overwrite the previous "changes"
changeset.

Anyway, if a race-free (thus, non predictible) changeset name is
determined by "changes", there must be a way for users (and scripts) to
know what it is. Either the name of the default output changeset must be
predictible, or it must be printed in the "changes" output, or the
ability to produce a changeset with an non-specified name must be
removed.

I do not quite understand why:

    tla changes -k ; tla changes -k

works, while

    tla changes -k & tla changes -k

causes an error... Is there some filesystem-level locking mechanism
involved?

Another command which exhibits the same behaviour is "undo". PyArch
works around the impossibility to know the name of the produced
changeset in advance by computing it itself and calling "tla undo
--output ,,undo-N". That cannot work concurrently, but that is required
to preserve the LIFO semantics of undo/redo.

In any case, I think it is important that default output file names be
either predictible or reported.

-- 
                                                            -- ddaa