gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Re: fixing and extending "selected commit"


From: Robert Anderson
Subject: Re: [Gnu-arch-users] Re: fixing and extending "selected commit"
Date: 04 Oct 2003 10:16:03 -0700

On Fri, 2003-10-03 at 14:43, Miles Bader wrote:
> > As for your suggestion, it does not meet my criteria for a good commit
> > process for one simple reason:  you never get a look at the revision
> > that will end up in the archive before it gets there.  To me, that is
> > unacceptable.
> 
> Who's `you' in this case, a pre-commit hook?  That's the only case where it
> conceivably makes a difference.

No, "you" is the user of tla.  Are you really missing this point
wholesale?  I find that hard to believe.  I'll state it a third way:

In my opinion, there should be an invariant for commit/get pairs: that
any tree that is created with "get" must be a tree that existed when a
"commit" command was given.

Why?  Because otherwise the pre-condition tree state for "commit" is not
the same as the post-condition tree state for "get".  The "get" tree
will in general never have existed, and if it hasn't existed, how can
you know what to expect from it?  And if you don't know what to expect
from it, why are you putting it in the archive?  It hasn't been
compiled, it hasn't been tested, it hasn't even been eyeballed.

So maybe you don't care about any of that: any old thing will do, and
it's not important to get a look at it first.  That's fine, and I've not
once stated that it shouldn't be possible to do that (like the case is
right now with file commits).  (Although I would recommend against it,
as a general programming practice.)

But what I am saying is that it is definitely a bad thing to have that
be the ONLY option.  Because then you, the user of tla, the careful
programmer, the guy who likes to make sure his code compiles and at
least sanity checks before committing, CAN'T do that.  And that would
suck.  If we're going to have one way to do it, it ought to be the way
that enables good habits, not the way that enables sloppy habits.

Bob






reply via email to

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