Re: [Gnu-arch-users] hook questions

[Dustin Sallings]

On Jan 14, 2004, at 16:38, Robert Collins wrote:

> On Thu, 2004-01-15 at 10:40, Dustin Sallings wrote:
> >         Is the locking really necessary at this point?  You know your latest
> > patch level, it will probably usually be safe to optimistically guess
> > the next one.  If you can't lock that when you go to commit, it's
> > because your tree is out of date and you abort the commit (which may 
> > be
> > aborted for a variety of reasons later, anyway).
>
> 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?

> >         The point is that at any precommit (prechangeset?) hook, you're not
> > guaranteed to get the revision number you think you might be getting
> > (or even commit at all).  As long as that's understood, there are
> > possibilities to do useful things with such hooks.
>
> 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.  :)

--
Dustin Sallings