On Wed, Jan 30, 2002 at 09:08:35PM -0800, Larry McVoy wrote:
> On Wed, Jan 30, 2002 at 11:58:11PM -0500, Alexander Viro wrote:
> > Suppose I have 5 deltas - A, B, C, D, E. I want to kill A.
>
> If you just want to make A's changes go away, that's trivial:
>
> bk get -e -xA foo.c
> bk delta -y"kill A's changes"
>
> all done.
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 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.
This is the reason why I have a 'linuxppc_2_4_galileo' tree.. it's got a
bunch of crap that will *only* ever be usefull to archeologists who want
to figure out my or someone else's thought process. The code is ugly. The
only reason I have another tree is because I want to work with other
people and keep a record for myself in case I break something in the
process.
Now, because I don't want to pollute the main tree, once this works, I'm
going to merge this stuff manually with dirdiff over to 2_4_devel, and
check it in.
And you're going to lose that information anyway (well, except on
openlogging.org, but that's just comments), because once I have this
working and checked into _devel, the _galileo tree is going to get
deleted because nobody cares.
It is usefull to note that the human brain has evolved the capacity to
forget. Yes, sometimes it makes a mistake and forgets the wrong thing,
but let's not be too quick to forget there may be a lesson here, and
everything is NOT always worth keeping.
If you don't have some capacity to 'lose' information in your distributed
database, there will come a point in time that it will stop being
scalable. Either moore's law may break, or information will be going in
faster than you can keep up by depending on faster CPU's/more memory/disk
space to handle all that history.
-- Troy Benjegerdes | master of mispeeling | 'da hozer' | hozer@drgw.net -----"If this message isn't misspelled, I didn't write it" -- Me ----- "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Schulz - 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:32 EST