In the course of something completely different, Linus Torvalds and others
were debating a way to deal with the idiosyncrasies of the 386 processor
(not all x86, but the 386 specifically). At one point H. Peter Anvin said:

Perhaps it's time to drop i386 support?

It seems to me that the i386 support has been around mostly on a "until
we have a reason to do otherwise" basis, but perhaps this is the reason?

They don't really arise in most normal situations. Bswap is trivial to
the extreme. Cmpxchg only comes up on SMP boxes. Right now the one big hit
is cmpxchg8 if you use direct rendering. And quite frankly if you use the
direct rendering infrastructure on a 386 its going to be a teeny bit slow
anyway 8)

So if anything its just not worth the effort of breaking the 386 setup
either 8). 386 SMP is a different issue but I don't see any lunatics doing
a 386 based sequent port thankfully.

And Linus replied:

Since the only person that comes to mind that would be crazy enough to
even _try_ to use Linux on 386-SMP is you, Alan, I'm really relieved to hear
you say that ;)

And no, it's not worth discontinuing i386 support. It just isn't painful
enough to maintain.

Note that the i386 has _long_ been a "stepchild", though: because of the
lack of WP, the kernel simply doesn't do threaded MM correctly on a 386.
Never has, and never will.

However, the known "incorrect" case is so obscure that it's not even an
issue - although I suspect that it means that you should not let untrusted
users run on a i386 server machine that contains any sensitive data. I could
cerrtainly come up with exploits that would work at least in theory (whether
they are workable in practice I don't know).

Using i386's for network servers is fine, of course. Just don't use them
for cpu farms (not that I think anybody is - it takes quite a big farm of
i386 machines to equal even _one_ PII ;)

In Issue #158, Section #2
(6 Mar 2002: Some Dissent Over BitKeeper)
, I
reported that some off-list BitKeeper discussion had finally made it to the
mailing list. Actually the thread was always on linux-kernel, but was still
ongoing, and so had been pushed into my next week's mail box. The thread I
saw had pealed away from the main branch and ended in time for me to catch
it.

Anyway, here is the rest of that discussion. The Open Source Club At
The Ohio State University (embodied by Michael Benedict, Colin Walters,
Matt Curtin, Martin Jansche, Balbir Thomas, Nicholas Hurley, Ryan McCormack,
and Shaun Rowland) said:

We, the undersigned members and officers of the Open Source Club at the
Ohio State University, are unhappy with the advocacy of the proprietary (http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/critique.html)
BitKeeper software for use in maintaining the Linux kernel. The Linux kernel
is an important symbol of Open Source and Free Software for many people, and
a project in which many thousands have participated in active development.
It is fine if some kernel developers choose to use BitKeeper on their own
machines, but officially endorsing proprietary software as the means of
working on the kernel is a large step backwards for Linux, and for the Open
Source and Free Software communities.

If the core Linux maintainers begin to advocate using BitKeeper, then there
will be strong pressure on these peripheral developers to use BitKeeper too,
since it would likely be easier than browsing the web-exported changelogs or
fetching the latest diff from kernel.org.

Using a closed-source, proprietary source control system for the kernel
is even worse than using other forms of proprietary software such as source
code analysis systems, because the revision control metadata (version numbers,
branches, changelog comments, etc.), would be stored in a format defined by
the proprietary software. This metadata is really a part of Linux, because
people will want to use it when talking about the kernel. Those who can't
(Perhaps they aren't connected to the internet regularly enough, for instance.)
or don't want to use BitKeeper are left out in the cold. One of the most
important parts of Open Source and Free Software is that we, the community,
are in control. But by using and advocating BitKeeper, we would lose part
of that control.

In summary, please do not advocate BitKeeper for use by the
general community. The Linux development process seems to have
worked up till now, and we can wait a little longer until Arch (http://www.regexps.com/#arch)
or Subversion (http://subversion.tigris.org)
are completed. Moreover, full-featured, completely functional
free versioning sytems are currently available, such as PRCS (http://prcs.sourceforge.net) and CVS
(http://www.cvshome.org). We respect
the kernel maintainer's freedom to use proprietary software for their own
purposes. And we ask the kernel maintainers to respect the community's
freedom from entrapment by proprietary software.

Andrew Morton replied:

fwiw, I prefer to not use bitkeeper, for the reasons which you outline.

That's my choice. Others have made a different one. I ask that they
ensure that their choice not inhibit my ability to contribute to Linux.

(At this point Andi Kleen began the subthread covered last week.)

Randy Dunlap also replied to Andrew, with complete agreement. Elsewhere,
Eric W. Biederman suggested that the people protesting BitKeeper do more to
create a free replacement instead of writing petitions. Rik van Riel also
agreed with that, saying,
"the choice between a
not-quite-free tool and no useful tool at all is easy."
Pau Aliagas
suggested trying Arch, but Rik didn't reply. Elsewhere, Alan Cox also replied
to the Ohio group, saying:

Right from the start Linus has always said he isn't going to force anyone
to use bitkeeper. End of story. If you think its free enough - use it,
if you don't (or you just think its crap software, dont use it)

In fact if it offends you enough to start a petition take the list of
names you get at the end and between you go write a better one under a
licence you prefer between the signatures.

Colin replied that development was already underway on those
replacements. He added,
"The petition never mentioned
"force". And even if Linus (and the other core maintainers) wanted to,
they couldn't *force* anyone to use BitKeeper. The issue at hand is the
strong pressure the official advocacy places on the perhipheral developers.
We (the signers of the petition), and others are unhappy with this.
That's what the petition says."
Zwane Mwaikambo replied,
"Already in development? Good stuff! Be sure to make
an announcement when its ready for production use, till then be a sport and
hop along."

Elsewhere and in the course of discussion, Alexander Viro said:

some of us are interested in creation of _WORKING_ software. Free is
preferable; GPL is usually tolerable; but all that isn't worth anything is
the design and code are crap.

Hypocrisy (or lunacy - take your pick) is coming from those who insist that
politically correct tools should be prefered even when they clearly suck.

If you feel that the worst problem is that non-free software exists - that's
your right. And your problem. IMNSHO the fact that majority of both free and
non-free software is choke-full of crap is slightly more troubling. YMMV.

He added,
"BTW, bitkeeper doesn't solve the
problems I have. Ditto for CVS. So I use neither. FWIW, BK is closer to
what I need. If it will ever get the things I need right - I'll use it and
damned if I'll hide that."
And Dave Jones replied:

Preach on brother Viro. Faced with the mammoth task of somehow syncing
a 6MB diff with Linus, I decided it was time to devote an afternoon (which
then turned into an evening) to seeing if bk can make this easier.

There's nothing in bk that makes my life any more difficult, and potential
for it to make it a *lot* easier. And Larry seems open to suggestions,
dispelling the "its closed commercial blah" myth.

Splitting bits up could become even easier soon if Larry and I figure
out a way to implement some of my perverse ideas for bending csets into
something more flexable than what they currently are.

Syncing from Linus to my tree isn't difficult, its the splitting bits
up to push his way that takes time. bk is halfway towards almost automating
this for me. CVS and friends don't even get to the start line here.

Hours of diff/grepdiff/filterdiff/vim, vs a few clicky clicky bits in
bk citool.

If you don't like the license, fine. Don't use it, but at least give
everyone else the option of making up their own mind before you try to force
_your_ opinion on others.

Elsewhere, in a completely different subthread, Andrew said:

I don't think anyone has been criticising bk featureset or reliability.
A few performance mumblings, maybe. It seems to be a fantastic piece of
software.

But that's not the point! Nobody, repeat nobody is happy with the
licensing thing. For some people, the day-to-day benefits outweigh the
philosophical concerns. For others they do not. That is what is being
discussed here.

I see two things being discussed here:

I don't want bitkeeper use to *decrease* my ability to do Linux
work. Linus will continue to push patches at the same rate, so
I have no problem. I'm OK with others using bitkeeper. EOT.

Kernel has a leading role in free software development. Other people do
not want kernel's use of bitkeeper to weaken that movement.

Me, I don't think the "movement" is weak enough for damage to come about.
And SCM is a space where the free tools are weak. It's a once-off special-case
and it's hard to see how anything bad will come about from it.

Also elsewhere, Cort Dougan said,
"I move
the PPC tree over to BitKeeper and it was worthwhile. I made rsync
updates and plain old 'diff' patches against Linus' tree available
nightly. It was easy and very quick to do that, I had it running
for nearly 2 years very well. In fact, you can still grab the patches from ftp://ftp.kernel.org/pub/linux/kernel/people/cort/.
What is your problem with BK apart from the license religion? Linus has
made it clear he'll provide patches in the same old style. I don't see
what you think you lose here. The gain for people who ship him patches
is well worth it. Before I handed the PPC tree over to Paul I would have
killed to get Linus to use BK so shipping him patches would be easier for
everyone involved. If I were still a maintainer my response would be a lot
less mild to those people that fight against BK on something so intangible as
"feelings" about the license. I put in a lot of hours shipping patches that
were for nothing, BK is helping avoid that for the current crew."

Elsewhere, Linus Torvalds said:

Guys, calm down.

A few points:

I certainly don't require BK use of anybody. It makes my life simpler
with some people (mainly the ones that tend to be maintainers of subsystems
and send me lots of patches), but there are many developers who do NOT use
BK, and it doesn't slow them down at all.

For example, see the FS patches from Al Viro: the only thing that BK has
resulted in as far as Al is concerned is that the changelogs are a lot better
and include his email comments.

And I also export my tree as regular patches, the way I always have (well,
the actual format changed subtly, but that's purely syntactic)

If Larry turns to the dark side (or, as some would say, the "even darker
side" ;) we're _still_ ok. The data isn't going anywhere, he can't close
that down. We'd just have to export it into a new format.

If worst comes to worst, and nobody has fixed CVS/subversion/whatever by
then, I can even just go back to how I used to work. Nothing lost.

If people in the open-source SCM community wake up and notice that the
current open-source SCM systems aren't cutting it, that's _good_. But it's
absolutely NOT an excuse to use them today. Sorry. I use CVS at work,
and I could never use it for Linux. I took a look at subversion, and it
doesn't even come close to what I wanted.

And I personally refuse to use inferior tools because of ideology. In fact,
I will go as far as saying that making excuses for bad tools due to ideology is
_stupid_, and people who do that think with their gonads, not their brains.

In short: nobody requires BK of anybody else. A lot of people really
like using it, though, and it does make some things easier. Some people
aren't convinced - David Miller is trying it out, and I haven't heard all
happy sounds from him about it. Others have taken to BK like fish to water,
and you'll pry it out of their dead cold hands.

The most productive thing people could do might be to just do a BK->CVS
gateway, if you really feel like it. Or just go on and ignore the fact that
some people are using BK - you don't actually have to ever even know.

Larry McVoy replied,
"We've thought of making a
readonly CVS pserver interface to BK which would at least make it easy to
get the source in some form that the GPL folks like. Somebody else should
be able to do that with a perl script. You could attempt a read/write
interface as well, that's a lot harder, the impedance mismatch between BK
and CVS becomes much more apparent in the read/write case."

This patch, in combination with the event logging and
event notification user library, provides a comprehensive event
logging package based on the draft POSIX standard 1003.25. See http://evlog.sourceforge.net/
for details and downloads.

A summary of the kernel patch:

A static kernel buffer is implemented for POSIX events logged
in the kernel. Size is configurable during kernel build.

If the buffer overruns the oldest events are kept, newest
discarded, and a count of discarded events is reported.

Optionally, POSIX events can be created from printk messages
(printk messages still go to /var/log/messages, as before)

registering facilities beyond the standard ones in syslog.h (device
drivers can have facility other than KERN)

Events are displayed on the system console as single-line summary messages
(based on printk's default console logging level).

Please be clear that this is NOT intended to replace printk and
syslog, but to coexist with them and provide additional
capabilities not available with printk/syslog that are highly
desirable in large servers and Telecom environments (to name a few).

Dominik Kubla felt that the buffer overrun handling posed a security
problem, in that an attacker could simply fill up the buffer and then
perform exploits that wouldn't be logged. Larry replied,
"Good point, but if the buffer is sized appropriately for the incoming
volume of events and the logging daemon is reading the events out of the
kernel buffer (as should normally be the case), then you would see the
events."
He added,
"The reasoning behind
this approach is to increase the liklihood that events indicating "root
cause" would be logged and not over-written by a flood of secondary events.
Keep in mind that only events originating in the kernel (or kernel module)
are stored in this buffer."

Elsewhere, Bernd Eckenfels thought Larry's patch would be quite useful, but
only if it were a replacement for netlink and printk, rather than something
intended to coexist with them. He felt that just adding another framework
would lead to kernel clutter. But Larry replied that it would be impossible
to get every maintainer to cooperate in switching the 41000 printk calls
already in the kernel, into his write functions. He said,
"Instead we want to provide enhanced logging features for new and
updated device drivers and other kernel code--more of a "slow migration over
time" approach. We provided the feature that creates POSIX event records
from printks so that System Admins, field service, developers testing and
debugging their code (just to name a few) could still take advantage of the
new tools provided with the user lib (too numerous to mention, but see the
spec on the website) for handling printk messages."

He added,
"Of course, even with better tools
there may still be those who only want to see printks in /var/log/messages.
It has even been suggested that events in the event log which did not
originate with printk should also be written to /var/log/messages, for this
very reason."
He and Bernd went back and forth on this for awhile,
and at one point Brian Beattie interjected:

I wonder if a slightly different approach might not be better. Instead of
adding extra kernel functionality, would it not be possible to define a text
format to messages and some SIMPLE macros, to allow printk's to generate
the desired information.

I understand about POSIX standards, but POSIX standards are not the
infallible word of of the diety of computing and sometimes are completely
bogos. While they do provide a thoughtful plan, they are not IMHO some
holy grail. for silly standards, see the recent stuff about names for K =
10^6 vs. K= 2^10.

So if one drops strict POSIX compliamce and goes for providing the
information, it maye be possible to provide some formating guidelines and
support to printk and some log analysis tools to provide 99% solution.

One thing to remember, is that the really hard and important part of
logging is not the part that can be legislated, or automated, it is making
sure that the correct events are reported in a accurate manner, and this is
not a one time job. This being the case, I would rather see effort expended
in rationalizing the current printk's and improving their use, than adding
some new infrastructure that may well be a perfromance drain and might even
be more prone to loss of log messages, than the current method.

Larry agreed that it was important to be skeptical of standards, but said,
"in this case the POSIX standard is not a standard,
but currently only a draft, and we (the Linux event logging team) have been
(and are continuing to be) directly involved it its writing, editing, and
(eventual, we hope) adoption as a standard."
He went on to say that
Brian's idea, while perhaps or perhaps not the way to go, was interesting. He
said,
"we have, in fact, been discussing how to
somehow get more information out of printk without asking kernel maintainers
to use a different API. Specifically, we thought about renaming the printk()
function and creating a printk macro. In the printk macro you would collect
source file name, line number and function name (and maybe some other useful
info), and then call the renamed printk function with the original message
plus the additional stuff (actually we were thinking call posix_log_write()
with the orig. message+addl. info and call the renamed printk with just
the original message)."
At this point, the discussion petered out.

Marcelo Tosatti announced,
"I've started
using BitKeeper to control Linux 2.4 source code. My latest tree can be
found at linux24.bkbits.net."
Stephen Torri replied sarcastically,
"If it was not enough that "bleeding-edge"
required a pint of blood but now we get BitKeeper access to the latest
and greatest. Cool! Maybe I should be on the regular shipment list from
the local blood bank. Keep up the good work. I certainly appreciate
it."
There was no reply to this, but elsewhere, some folks had some
problems grabbing Marcelo's tree. At one point, Ben Greear said he'd used
'bk clone bk://linux24.bkbits.net/linux-2.4' to clone the tree,
but added,
"However, I see no files, only directories.
The files do seem to be in the SCCS directories, but I don't know how to
make them appear in their normal place."
David Woodhouse replied:

Type 'make config'. Make is clever enough to get the Makefile from SCCS
for you. Add the missing dependencies to the Makefile so that make will
fetch stuff like scripts/Configure before trying to run it, etc.

Making it get all the Config.in files by parsing arch/$(ARCH)/config.in
is a fairly trivial task... but you do need to explicitly check out all the
include directories, because we don't know how to deal with that yet. With
kbuild-2.4, make dep won't work very well, but kbuild-2.5 ought to be OK
with everything but the include files, I think.

Or you could just check it all out beforehand with bk -r co.

Larry McVoy asked if anyone had successfully used the 'make config'
incantation in that situation, saying that it would save a lot of space and
performance if it worked. But Linus Torvalds replied:

Hey, the _sane_ way to do it is to not have all those crappy SCCS
dependencies in all the tools, but to simply make a bk work area be a real
file tree!

Larry, your argument that there are tools that are SCCS-aware is just not
sane. For each tool that is SCCS-aware, I will name a hundred that are not,
and that you're not going to fix. The only sane way to make _everything_
bitkeeper-aware is to keep the tree checked out and to keep the bitkeeper
files somewhere else.

Right now simple things like command-line completion and

find . -name '*.[chS]' | xargs grep xxxx

do not work, because they either don't find files or they find the wrong
ones (the internal bitkeeper files etc).

I'd much rather have a separate working area, ie if my repository is
under ~/BK/repository/kernel/linux-2.5, then the checked out tree would
be under ~/BK/repository/kernel/linux-2.5/workarea, and I would just have
a simple symbolic link from ~/v2.5 to the workarea (and never even _see_
the BitKeeper files unless I thought I needed to).

None of this "special tools for normal actions" crap.

A couple of posts later, he went on:

The fact is, mixing up the revision control directories and the working area
is a design mistake, and one that BK perpetuated due to Larry's infatuation
with the fact that "make" and "patch" already know how SCCS works.

(It should be noted that this design mistake is also one of the stumbling
blocks for ever improving the BK databases. It limits your viability in the
long run, which is why I'm trying to prod Larry into fixing it).

Larry replied:

The "design mistake" was made so that I could have BK generate pure SCCS
files and test that I did the same thing as a known working tool, ATT SCCS.
By doing that, I easily saved myself a year of design. Making interleaved
deltas work is hard for me (we have Rick here now and he's forgotten more
about this stuff than I'll ever know, but we didn't have him when I wrote
the SCCS compat weave).

At this point, I trust our implementation of the weave more than I trust
the ATT one, and ours handles several cases that theirs doesn't, so I'm a
lot less concerned about that compatibility.

And we know that we can get better performance, and dramatically reduce
fragmentation, by sticking all the files in one big file, and we've known this
for a long time. We're gonna do it, you're gonna love, it's less filling,
it tastes great. There is only so many things that we can do at once and
this is on our short list, but it isn't at the top. Keep that in mind as
you push us to make enhancements, there is no free lunch, so prioritize.

I'm gonna hack at least make & patch to know about the new format and work
the way they do now. So I can have your cake and eat it too. If I can't
get the FSF to take the changes, we'll just ship 'em, we ship diff &
patch already, so it's not so hard to alias make='bk make'.

the BIOS on our machines (Phoenix) uses IO-port 0x80 for storing POST
codes, not only during sytem startup, but also for messages generated during
SMM (system management mode) operation. I have been told other BIOSs do
the same.

Unfortunately we can't read this information because Linux uses port 80 as
"dummy" port for delay operations. (outb_p and friends, actually there seem
to be a more hard-coded references to port 0x80 in the code).

It seems this problem was always there, just nobody took notice of it yet
(at least in our company). Sometimes people wondered about the weird POST
codes displayed in the LCD panel, but who cares once the machine is up...

Would it be too outrageous to ask that this port number be changed,
or made configurable?

Richard B. Johnson replied,
"This is a
'N' year-old question. Do you know of a port that is guaranteed to exist
on the Intel/PC/AT class machine? If so, submit a patch. I proposed using
0x19h (DMA scratch register) several years ago, but it was shot down for
some reason. Then I proposed 0x42 (PIT Misc register), that too was declared
off-limits. So I suggested that the outb to 0x80 be changed to an inp, saving
%eax on the stack first. That too was shot down. So, you try something... and
good luck."

Someone suggested making it a config option, but Martin Wilck said even
a #define and a comment in the source, explaining how to change
the port for a given setup would be sufficient. Later, Martin announced:

this patch makes the use of the "dummy" port 0x80 globally configurable
through a macro in the (new) file asm-i386/iodelay.h. I think nobody wants
to see this in the configuration menus.

I have tried to capture all accesses to port 0x80, although some may
have escaped.

Even if nobody wants to use anything other than 0x80 in the near future,
I think the patch is useful because grepping the source for 0x80 is really
no fun.

for development resync against the kernel24.bkbits.net tree? It looks
like the changes from 2.4.18-pre8 onwards all have different patch IDs in
the new tree; so when I try to do a pull from my current repository I get
tons of conflicts, if I try to do a receive of just the patch set I get a
resync error:

The thought of taking everything back to the common ancestor and then
trying to apply the changes one at a time and adding the change logs by
hand isn't that appealing (I have 3 2.4 repositories, some with upwards of
10 additional change sets in them).

Jeff Garzik replied,
"Just do a 'bk pull' on
my marcelo-2.4 tree. Since it is based on the original linux-2.4 tree
just like Marcelo's tree, I was able to merge from my 2.4 line to his 2.4
line."
But James said when he'd tried this he got a slew of initial
rename conflicts. Jeff replied,
"This is normal,
you just need to accept the remote changes for all those new/renamed files.
BitKeeper doesn't support doing this automatically for all files, so I had
to highlight the expected BitKeeper response in another window, and then
click <paste> on my mouse around 300 times... (~300 new files)."

Larry McVoy retched into his hand, and offered to add an option to allow
automatic acceptance. But he added that he suspected there was some sort of
problem. He asked what Jeff's situation had been. Jeff replied:

I started with Linus's linux-2.4 repo and so did Marcelo. We independently
checked in 2.4.recent patches (including proper renametool use), which
included the ia64 and mips merges, which added a ton of files. When you do a
'bk pull' from Marcelo's linux-2.4 into my old marcelo-2.4 repo, you have
to individually tell BitKeeper that you really do want to trust Marcelo's
copy over my own, for each of the ~300 new files that were added between
Linus's linux-2.4 repo creation and 2 days ago. So I highlighted "rl\ny\n"
in another window, and wore out my middle mouse button... Renames could
have been handled similarly, but there were few renames, so I just typed
"r\ny\n" manually maybe 10 or 20 times.

One could argue that a "rla" or "lla" command would be useful when resolving
a conflict between two new files, telling BitKeeper to accept remote (or
local) additions in this case _and_ all succeeding cases.

One could also argue that BitKeeper needs to be twacked on the head
because it is not detecting that the file-creates and file-renames are 100%
the same, content-wise.

Larry replied to the fact that Jeff and Marcelo had independently checked in
some recent patches. He said:

OK, so there is the root cause. It's time to talk about duplicate
changes. You know how Linus hates bad csets in the history and doesn't
want them there? Well, I hate duplicate csets and don't want them there.
There are lots of reasons. One reason is that it means revtool is a lot
less useful for debugging. If you are trying to track down the change which
caused a bug but it is obscured by a duplicate patch, you just got hosed.
Another reason is file creates. Suppose you and Marcelo both created a file
called "foo". You pull, there is a file conflict, you remove one of the
two files. It isn't actually removed, it's just moved to BitKeeper/deleted.
Time passes and you or someone else is fixing bugs in a pre-merged copy
of the tree and you are updating "foo". You later pull that bugfix into
the merged tree and the bugfix happily is applied to the *deleted* copy of
the file, since the changes follow the "inode", not the pathname. Bummer,
you are now scratching your head wondering where your bugfix went.

There are things we can do in BK to deal with this, but they are not
easy and are going to take several months, is my guess. I'd like to see if
you can work around this by avoiding duplicate patches. If you can, do so,
you will save yourself lots of grief.

If you get into a duplicate patch situation, you are far better off to pick
one tree or the other tree as the official tree, and cherrypick the changes
that the unofficial tree has and place them in the official tree. Then toss
the unofficial tree. I can make you a "bk portpatch" command which does this,
we have that already, it needs a bit of updating to catch the comments.

You really want to listen to this, I'm trying to head you off from
screwing up the history. If you get 300 renames like this, it's almost
always a duplicate patch scenario.

Jeff replied:

I know why it happened, silly.

This was just an example of a real world example that actually happened,
where BK sucked ass :)

Marcelo's BK tree did not exist when I created my marcelo-2.4 tree.
marcelo-2.4 repo existed for a while and people started using it. Once Marcelo
appeared with his "official" BK tree, people naturally want to migrate.
There were two migration paths: (1) export everything to GNU patches, or
(2) click the mouse 300 times.

So, knowing that duplicate patches are a bad thing helps not in the
least here...

A post or two later, he went on:

a fair question would be, is this scenario going to occur often? I don't
know. But I'll bet you -will- see it come up again in kernel development.
Why? We are exercising the distributed nature of the BitKeeper system.
The system currently punishes Joe in Alaska and Mikhail in Russia if they
independently apply the same GNU patch, and then later on wind up attempting
to converge trees.

Do you see what I'm getting at? In a widely distributed SCM system for an
open source project, chances are -good- that some random two or more people
will independently apply the same patch.

Larry replied:

The real problem is N sets of diffs being applied and then merged.
The revision history ends up with the data inserted N times.

I'm not sure what to do about it. I can handle the duplicate inode case
more gracefully but it's a heavy duty rewack.

We could play games where we detect the same patch inserted multiple
times and refuse to merge them. Hmm. Hmm. Not sure that helps.

Jeff said:

Hence my suggestion for a short term solution that's immediately useful --
allowing some way to answer "local changes take precedence 100% of the time"
or "remote changes ..." with a single command. That was my hack solution that
I thought would people might find useful when stuck with the duplicate-patch
situation.

In the command line merge tool, when merging a file-create, "rla" would
cause the current file conflict, and all future file-create conflicts, to be
"won" by the remote side -- essentially creating the effect of typing "rl"
300 times. Apply similar logic to the file-rename merge case. I think the
merge command I used in 100% of the cases, during that merge, was 'r'.

If you are stuck with the duplicate patch case, as happened here, I just
want to see the pain eased a bit :) IMO you can put off the hard problem
if you make the UI a bit better.

Christer Weinigel also suggested,
"One
variant of this would be to automatically use the remote file as long as
the file contents are the same. That way, if I apply a patch locally and
Marcello/Linus later apply the same patch and put it into the official tree,
I can use the official version. This would probably handle most of the
conflicts I have seen so far. If there are any "real" conflicts, I can
handle them manually."

Linus announced 2.5.7 and added,
"NOTE! I'll
be gone for a vacation for two weeks, and will not be reading email during
the time. So please discuss problems on linux-kernel, with Dave Jones,
Jeff Garzik etc handling patches while I'm away."