Re: A modest proposal -- We need a patch penguin

[Larry McVoy]

Troy said:
> The real problem with this approach is it leads to information overload.
> 
> Go look at linuxppc_2_4_devel with sccstool and try to track major 
> changes over the last 6 months. 
> 
> You can't. You are completely overwhelmed by the day-to-day thrashing of 
> 'bug fix this, bug fix that', and all the lines on the screen from the 
> wacky merges we wind up doing in that tree.

I agree with this and the rest of your message.  Here's what we are doing
to address it:

a) I have a version of BK where revtool (aka sccstool) shows only the 
   tagged releases.  It's cool.  It also has a feature where you can
   select a node and ask it to color all versions which contain this
   node (seems like you'd never need that until you see a heavily used
   BK tree like Troy has).

b) part of the problem is the "merge" deltas in the ChangeSet file.
   They really need to be hidden or removed completely.  As a side
   effect of making the ChangeSet file more flexible a la Linus' 
   requests (doesn't give all that he wants but part of it), I 
   think these will go away.

c) LODs.  One thing a LOD can do for you is to allow you to have your
   private LOD into which you do a ton of changes.  Then you can do
   a "rollup include" into a public LOD, like the PPC LOD.  We then
   give you a LOD aware revtool and the information overload starts
   to go away (but preserves the information if you need it).

> I think what Linus and Viro really want is not to rewrite history
> (although there are times when it would be nice), but say "I don't think
> this change is worth looking at". Keep the data in the database, because
> you have to to maintain consistency, but don't let me see it unless I ask
> 3 times, and say please.

If we could agree that this is true, I'm ecstatic.  BK needs at least part
of what you said to be true.  If you can convince Linus that it doesn't 
matter if the data is there as long as his view is clean, that solves some
of the nasty problems.

That said, I'm sympathetic to the "I make lotso changes and I want to 
collapse them into one big change" problem.  It's certainly technically
possible to make BK do that, but then you have to *know* that nobody
else has a BK repo with your old detailed changes in it, or if they 
do, they won't ever try to push them back to you (or Linus or ...).  
It's not an error if they do, it's just that BK will view them as 
different changes and automerge them right back into the history.
So then you'll have both the collapsed version and the detailed version
which puts you worse off than when you started.

That's the whole issue with the "history rewrite".  I'll give you history
rewrite, but you need to understand what it means.  I think the current
BK users get it.  I think the BK future users don't get that it is all
one big replicated distributed slightly (or not so slightly) out of sync
database that wants to sync up when it can.  So if you rewrite history,
BK has no way of knowing that you did that.  I suppose we could teach
though so that it would reject the uncollapsed changes but that has its
own issues.