linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Larry McVoy <lm@bitmover.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Larry McVoy <lm@bitmover.com>
Subject: Re: [PATCH] struct page, new bk tree
Date: Tue, 19 Feb 2002 15:57:06 -0800	[thread overview]
Message-ID: <20020219155706.H26350@work.bitmover.com> (raw)
In-Reply-To: <Pine.LNX.4.33L.0202192044140.7820-100000@imladris.surriel.com>; from riel@conectiva.com.br on Tue, Feb 19, 2002 at 08:47:17PM -0300

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.

Do you think this would be useful?  Would you use it if we made it?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

  reply	other threads:[~2002-02-19 23:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-19 23:47 Rik van Riel
2002-02-19 23:57 ` Larry McVoy [this message]
2002-02-20 19:07   ` Andreas Dilger
2002-02-20 19:27     ` Rik van Riel
2002-02-20 20:17   ` Ed Tomlinson
2002-02-20 20:26     ` Jeff Garzik
2002-02-20 20:31     ` Larry McVoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020219155706.H26350@work.bitmover.com \
    --to=lm@bitmover.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox