[Top][All Lists]

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

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] [BUG] Race condition in changes
Date: Sun, 30 May 2004 21:50:09 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040306)

David Allouche wrote:
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"

Well, since they're marked as junk, I guess that's kosher. They shouldn't be there at all, and I don't know what kind of person would use the -k option (-o I can understand). My previous changesets are only there because tla abandons them when it gets a SIGPIPE.

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.

That reminds me: pyaba's now got a native 'changes' command based on 'tla delta'.


reply via email to

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