Messages in this thread | | | Date | Wed, 20 Feb 2002 12:07:51 -0700 | From | Andreas Dilger <> | Subject | Re: [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/
| |