>Sigh. OK, I'm taking one more pass at trying to get you to see the light
>and then I give up.
And I'm trimming the cc list back a bit...
> > I'm not quite sure how Linus does this, but how I'd do it is [a really
> > complicated solution based on patches that won't work]
A) It's not really all that complicated. The minimal commands are "untar"
and "patch". If you don't feel like doing fixups at all (with a third
command, an editor), the rejected patches can be bounced. It does mean
you're keeping track of patches manually, but I'm just talking about what
happens between -pre releases, which is not an infinitely large set of
patches to wrangle...
B) It's a solution that is working, and has been for years. It certainly has
its disadvantages, but it does in fact function. What the existing process
is used to do on a regular basis is the definition of the minimum level of
functionality I would expect from bitkeeper.
I'm not defending the patch method. I'm certainly not advocating it as the
ultimate solution. But it has worked for years, and a replacement that can't
easily do things it can easily do seems flawed to me.
If you'd like to say that I'm wrong about bitkeeper and that it CAN easily do
the above. (That's kind of the reply I expected.) But attacking the
desirability of doing things that the existing patch managment process
handles on a fairly regular basis... Seems counter-productive to me.
> Think. What you are describing is basically what Linus does today. And
> noone, including you, is happy. You're the guy who started this thread.
I wasn't trying to get Linus to use CVS. That's just a fringe benefit. I
was trying to figure out how to deal with patches getting dropped to the
point people were suggesting automatic remailers. I didn't directly suggest
changing what Linus did with patches on his own hard drive. I went out of my
way to craft a proposal where he DIDN'T have to change any of that. I was
mostly talking about the method by which patches got to him, which is where I
(right or wrong) percieved the existence of a problem.
You can say I suggested the wrong solution, and you can say I identified the
wrong problem. But please don't project your desires onto me and try to use
that to explain why you think I should be agreeing with you.
To clarify: I'm HAPPY to see Linus giving bitkeeper another try. I think
this is an EXTREMELY positive development. I do NOT want to discourage it.
I also don't want to see it fail because you expect Linus to adapt to
bitkeeper rather than trying to understand what Linus does and adapt
bitkeeper to be a good tool for him.
(Some of these are simple documentation questions. How does Linus do THIS.
And I intend to go RTFM when I have time to tackle a new project (I.E. not
tonight), but I'm mostly following up on your replies to questions other
people originally asked, which I didn't consider to be a real answer to the
question.)
> However, what you described *completely* misses the point.
The message you're replying to was answering your question, which to me
seemed to be you changing the subject form the earlier "people have to send
linus patch A in order to send him a bitkeeper change set with patch B, even
if they don't want to". I wasn't talking about what goes on within Linus's
tree, it's about what people send to him. (Bitkeeper change sets seem to
have descriptions and potentially automatic notification back to the original
patch submitter that they got looked at and/or applied, which is a potential
improvement over raw text patches. The ordering requirements do not seem to
me to be a pure improvement, but instead something that takes extra effort to
work around.)
> Do you start to see the problem? You were yelling and screaming
> "BitKeeper sucks because it can't take a patch out" when in fact
> it can do exactly what you said it can't.
Yelling and screaming? Was I? (I think you read too much into the rant tag.
The point of one of those things is "not everybody is expected to agree with
me on this"...)
There's a difference between "if you can't take the patch out, then maybe
bitkeeper sucks" and "bitkeeper definitely sucks because I just KNOW you
can't..." You seem to have missed the conditional and homed right in on
defending your baby from hypothetical criticism. Maybe I'm not expressing
myself clearly. It's happened before...
You just answered my question: bitkeeper can take the patch out, the problem
isn't a real problem. Thanks, that's what I wanted to know.
> On top of that, what you
> were complaining about isn't the point. The thing that you say
> BK can't do, but it can, is not what Linus wants. Not even close.
>
> And you haven't begun to understand that BK is a distributed, replicated
> system. You can turn all that off and you've got CVS, so turning it
> off isn't an option.
If you turn off the distributed/replicated nature of bitkeeper, it acquires
problems with file renames and reproducibility? Without being distributed,
you have problems with file renames and reproducibility? Several other
developers use a CVS or BK repositories which nobody else ever directly
checks any code into. They import patches, and then do their own development
in that tree. The source management system is purely for their own
convenience. Code goes to other developers as unified diffs.
I'm not talking about fun bells and whistles with which Linus could IMPROVE
his process. I'm trying to make sure there are no holes that stop him from
doing what he could do before. (There SHOULDN'T be. But if there aren't,
why did it take so long to adopt? Seems worth a check. Several people who
use bitkeeper have said things along the lines of "I want to do this and
haven't figured out how", and you actually seem to have replied "no you don't
really want to do that" on more than one occasion. I'm hoping this is a
miscommunication, which is why I'm trying to follow up. I mostly just wanted
clarification and reassurance...)
> Leaving it on means that the revision history is replicated.
You seem to have an unquestioning assumption that infinitely replicating the
revision history is a good thing.
Linus himself seems to have denied this assumption. Just because a
downstream developer took two months to come up with a subsystem and did
eight hundred seperate checkins of which only maybe 20% of the code made it
into the final version, does NOT mean that Linus cares. That level of detail
IS more information, but there's a limit to how much information you want
before it becomes cruft in Linus's tree.
> So it isn't an option to collapse a pile of changes into a smaller pile,
> the bigger pile will come back the next time he updates
> with the other tree.
And I'm saying I'm not convinced this is necessarily a good thing.
> And once again, you come back with another post that shows you just want
> to yell
I occasionally use caps to emphasize a word because you can't put italics or
underlines in non-html email. I do not however PUT MULTIPLE CAPITALIZED
WORDS TOGETHER. That is shouting, yes...)
> and you haven't thought it through, into my kill file you go,
By all means. I've made it back into Al Viro's now. (I'm a bit confused how
I managed to get OUT of it, but I probably changed email addresses...)
Generally, I don't consider putting my fingers in my ears and going "la la la
I can't hear you" to be the logical equivalent to proving your point in an
argument. When I don't feel progress can be made, I generally just stop
replying.
> my blood pressure goes down, you get to yell all you want, everybody
> is happy. I'm willing to try and make BK do what is needed here; I'm
> not willing to tolerate people who don't think.
And of course the other person not seeing your point is always entirely
because they're all not thinking? There's no possibility of legitimate
miscommunication, or legitimate difference of opinion about anything?
That must save time.
Rob
-
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/