lkml.org 
[lkml]   [2002]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] struct page, new bk tree
On Feb 19, 2002  15:57 -0800, Larry McVoy wrote:
> On Tue, Feb 19, 2002 at 08:47:17PM -0300, Rik van Riel wrote:
> > I've removed the old (broken) bitkeeper tree with the
> > struct page changes and have put a new one in the same
> > place ... with the struct page changes in one changeset
> > with ready checkin comment.
> >
> > You can resync from bk://linuxvm.bkbits.net/linux-2.5-struct_page
> > and you'll see that the stupid etc/config change is no longer there.
>
> Since you two are doing the BK dance, here's a question for you:
> I can imagine that this sort of back and forth will happen quite a bit,
> someone makes a change, then Linus (or whoever) says "no way", and the
> developer goes back, cleans up the change, and repeats. That's fine for
> Linus & Rik because Linus tosses the changeset and Rik tosses it, but
> what about the other people who have pulled? Those changesets are now
> wandering around in the network, just waiting to pop back into a tree.
>
> This is at the core of my objections to the "reorder the events" theme
> which we had a while back. You can reorder all you want, but if there
> are other copies of the events floating around out there, they may come
> back.
>
> A long time ago, there was some discussion of a changeset blacklist.
> The idea being that if you want to reorder/rewrite/whatever, and your
> changes have been pulled/pushed/whatever, then it would be good to be
> able to state that in the form of some list which may be used to see
> if you have garbage changesets.
>
> We could have a --blacklist option to undo which says "undo these
> changes but remember their "names" in the BitKeeper/etc/blacklist file.
> The next changeset you make will check in that file. Note that each
> changeset has a unique name which is used internally, somewhat like a
> file has an inode number. So we can save those names. Then if you do
> a pull or someone does a push, the incoming csets can be compared with
> the blacklist and rejected if found.

So what happens to the person who pulled the (now-blacklited) CSET in
the first place? If they do a pull from the repository where the original
CSET lived, will the blacklisted CSET be undone and the replacement CSET
be used in its place?

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.073 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site