Re: [Gnu-arch-users] hook questions

[Robert Collins]

On Thu, 2004-01-15 at 12:17, Dustin Sallings wrote:
> On Jan 14, 2004, at 16:38, Robert Collins wrote:
> >
> > Yes, it's necessary. Otherwise you'll end up with commit sequences like
> > this:
> >
> > patch-X contains 'patch-X' in the files.
> > patch-Y contains 'patch-X' in the files.
> 
>       I guess I don't understand this one.  How does patch-Y get ``patch-X'' 
> in the files if the commit was aborted after the rewrite?  You'd have 
> to commit again before you could get to patch-Y, and the files should 
> be rewritten to say ``patch-Y'' at that point, wouldn't it?

Npo, because if you don't lock where I'm suggesting, the race condition
can allow two competing commits to both succeed:

commit A sees that X-1 is the current
commit B sees that X-1 is the current
commit A & B both set X in their files.
now, A is a slower machine, and B 
locks, commits, unlocks
before A trys to lock.

> > Such as ? All the key ones that can't be done before running tla commit
> > seem to involve the changeset id.
> 
>       Well, that's true for the things I was thinking as well.  The question 
> is really whether it's practical.  In many cases, it's perfectly 
> acceptable to have it be part of the build process...just not for 
> script and things.
> 
> >>    As for locking as late as possible, I've been having a problem with
> >> the lock being created when I go to commit before it realizes that 
> >> I've
> >> screwed up again and am committing to a mirror.  This implies to me
> >> that the locking happens a little too early in some cases.
> >
> > Oh yes, that bug I've seen, haven't fixed yet.
> 
>       I don't complain about it too much since it's typically because I did 
> something stupid.  :)

it's bad UI, and needs fixing ;).

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part