Hi Linus,
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.
If you want to wait a version with pulling this change because
of the pte_highmem changes by Ingo and Arjan I can understand
that and will just bug you again in a version or so ;)
kind regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
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
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/
On Wed, 20 Feb 2002, Andreas Dilger wrote:
> 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.
> > 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.
> > We could have a --blacklist option to undo which says "undo these
> > changes but remember their "names" in the BitKeeper/etc/blacklist file.
> 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?
That's a good question. I hadn't answered Larry before because
I just couldn't come up with what the implications of a blacklist
would be or how it would ever work ...
regards,
Rik
--
Will hack the VM for food.
http://www.surriel.com/ http://distro.conectiva.com/
In my opinion the idea of cset -x (while usefull) is fundamentally
broken. The result of this is that ideas like blacklist need to be
considered. I would propose instead an undo -x, that would
generate a cset to reverse the one following the -x. This might
lead to conflicts - these would be resolved the normal bk fashion.
If bk handled ?bad? csets in this manner there would be no need for
blacklists - it is more robust in that you can always used undo -x.
Comments?
Ed Tomlinson
On February 19, 2002 06:57 pm, 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.
>
> Do you think this would be useful? Would you use it if we made it?
Ed Tomlinson wrote:
>
> In my opinion the idea of cset -x (while usefull) is fundamentally
> broken. The result of this is that ideas like blacklist need to be
> considered. I would propose instead an undo -x, that would
> generate a cset to reverse the one following the -x. This might
> lead to conflicts - these would be resolved the normal bk fashion.
> If bk handled ?bad? csets in this manner there would be no need for
> blacklists - it is more robust in that you can always used undo -x.
Well, if the changes are properly split up, you shouldn't need to do
this... In the ideal situation it is easiest for Linus to accept or
reject a "bk pull" in its entirety. Then he can just do a "bk unpull"
Jeff
--
Jeff Garzik | "Why is it that attractive girls like you
Building 1024 | always seem to have a boyfriend?"
MandrakeSoft | "Because I'm a nympho that owns a brewery?"
| - BBC TV show "Coupling"
On Wed, Feb 20, 2002 at 03:17:12PM -0500, Ed Tomlinson wrote:
> In my opinion the idea of cset -x (while usefull) is fundamentally
> broken. The result of this is that ideas like blacklist need to be
> considered. I would propose instead an undo -x, that would
> generate a cset to reverse the one following the -x. This might
> lead to conflicts - these would be resolved the normal bk fashion.
> If bk handled ?bad? csets in this manner there would be no need for
> blacklists - it is more robust in that you can always used undo -x.
First of all, cset -x is functionally equivalent to what you call
undo -x. They do the same thing. Second of all, cset -x is _much_
better. It does the same thing without introducing any new diffs
into the history. Go get a test tree, make a changeset, clone
the tree, cset -x the changeset, and diff the revision history files.
All you will see is something like this:
^As 00000/00000/00455
^Ad D 1.32 02/02/20 09:50:05 lm 33 32
^Ax 32
^Ac Exclude
^AcC
^AcK50774
^Ae
The "^Ax 32" line says "exclude the change who's serial number is 32".
No reverse diffs applied to the file. Much nicer. Merges work like
this too, in reverse, it just includes the branch deltas.
But all of this misses the real point - Linus, with justification, doesn't
want the revision history cluttered up with
Idea 1.
Remove Idea 1.
Idea 2.
Remove Idea 2.
But we need some way to let changes get into the system so others can review
them, test them, merge them with their stuff and test, etc. But then when
they are found to be wanting, we need a way to tell other people that those
csets are verboten.
I'm open to suggestions, this is a much harder problem than it appears
because of the fact that the revision histories are all replicas
possibly with local data. Unlike CVS, there is no one place to go to
edit the RCS files and obliterate some change.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm