On Wednesday 30 January 2002 08:57 pm, Larry McVoy wrote:
> On Wed, Jan 30, 2002 at 06:18:11PM -0500, Rob Landley wrote:
> > > And you just lost some useful information. The fact that so-and-so did
> > > fix A and then did B is actually useful. It tells me that A didn't
> > > work and B does. You think it's "crap" and by tossing it dooms all
> > > future developers to rethink the A->B transition.
> >
> > <rant>
>
> I'll see your rant and raise you a nickel.
>
> > If developers can't ever make temporary changes to their tree which they
> > do NOT intend to send to linus, they can't FUNCTION. (Except my not
> > doing development in said tree.)
>
> Of course they can do that. They get to decide what they push and
> what they don't. I don't think you understand BK.
Entirely possible. Quite likely in fact, I'm trying to pick it up as I go
along. (I've fired up the docs, but haven't had time to read too far yet.
Trying to finish some paying work before hitting LWE tomorrow.)
> What we are talking
> about is the problem that the change has been committed to CVS, other
> changes are built on top of it, and now Linus realizes that the change
> was bad news.
The inflexibility of CVS relative to simply applying or reversing patches to
a source tree on disk is a documented reason Linus doesn't use CVS. Don't
compare to CVS, compare to what Linus is currently using. Beating a straw
man doesn't HELP.
> The problem is extracting stuff out of the middle which
> has already been built upon for more stuff. How would you propose solving
> that problem because that is the problem statement?
I'm not quite sure how Linus does this, but how I'd do it is keep around the
last shipped tree and assemble a patch set against it. If stuff gets really
screwed up (a change in the middle needs to be reverted but doesn't unapply
cleanly), then you can always revert back to the last shipped tree, re-apply
the patches before the dead one, and then re-apply the patches afterwards
fixing up rejects as necessary. (And if I were Linus and the fixup took more
than 30 seconds, I'd probably throw the dependent ones back down to a
lieutenant or maintainer with a quick and dirty explanation and have THEM
fixup the diffs, possibly by making them apply cleanly to the next released
-pre version and submitting them again then.) Bounces and even reversions
due to conflicts are eminently understandable and part of the cost of doing
business. (It can be annoying at times, but debugging always is...)
This isn't me trying to make policy, this is me trying to guestimate what's
going on today. (I'm not trying to speak for Linus, just explain my
understanding of how Linus works.) Now that needs to translate into
bitkeeper, and if it's HARDER to do in bitkeeper, bitkeeper probably needs to
be fixed.
> If someone sends Linus a patch, he checks into BK or CVS or whatever,
> he then gets 5 other patches and applies them in BK/CVS, and THEN he
> wants to take out the first patch, how would you suggest we do that?
If the patch no longer unapplies cleanly, then a reversed patch to take it
out may have to be applied to the tree. In Linus's tree, this can also
happen if he's shipped a -pre release with the old patch in it, so reverting
it would need to be in the next incremental patch Linus releases anyway
because we're beyond a checkpoint. (Write barrier, changes committed to
kernel.org, no longer able to be reordered in cache...)
But if the patch DOES unapply cleanly, and we haven't checkpointed yet,
there's no good reason Linus can't just revert it. There should definitely
be an option to delete all traces of it from the hierarchy (carving moses'
name off the pillars and all that).
Reverting a change out of order should not ARTIFICIALLY cause conflicts just
because that's not the way bitkeeper expects people to think. That would be
another case of "false dependencies", and gets us back to Linus' backmerge
concept. This is sort of reverting a backmerge.
When there is a logistical problem with simply reverting a change because
other changes really are on top of it, then logically the removal is either
sort of a patch, or the later changes need to be temporarily reverted and
fixed up before being reapplied. (This is not conceptually new, as I said it
happens with patches all the time. Whether bitkeeper provides better tools
to do this than diff, patch, and vi do is an open question. It might be
possible to make some sort of "--force --nodeps" way to revert a patch by the
short and curlies, followed by a manual fixup of the patches that went in on
top of it with that "bitkeeper fix -c" thing, but probably isn't worth the
effort and I'm just not going there right now.)
But pointing out that "that history is valuable, leave the old residue in the
tree even if it hasn't been sent out anywhere yet" is bogus. Between
checkpoints, Linus could translate his entire tree into fortran and back if
he wanted to, and nobody else should ever have to care if he doesn't want
them to. The set of changes Linus chooses to ship to turn pre7 into pre8 is
his choice, not yours.
What Linus seems to want is the shortest and most convenient straight line
from checkpoint to checkpoint to be stored in his tree. (Basically, like the
patch files he puts out NOW, only more granular, with his changelog
information broken up and stored with each change.) How can bitkeeper
provide THAT? (If it can do more, great. But if it can't provide this basic
functionality without some bell or whistle interfering and making it hard to
use, then there's a problem. Please be very clear when you're talking about
an an enhancement over and above this level of functionality when it is NOT a
requirement...)
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:30 EST