[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Linux Kernel Subversion Howto
On Sun, 6 Feb 2005, Larry McVoy wrote:
> [Larry continues to pull numbers out of his arse.]
Out of sympathy to Al I cut the crap short. If you (or anyone else) really
want to know, contact me privately.
The 85% number is of secondary interest only anyway, my (undisputed)
argumentation still stands, why the 44% is more important.
> > Well, I'm not the one who claimed "We don't do lockins. Period."
> > I'm just trying to figure out what that means...
> Hey, Roman, the statement above stands. You made the choice that you want
> to go write a competing system. If you hadn't you could just use BK and
> stop whining. Since you have made that choice, which is your right,
> how about you produce your competing system? And stop whining that
> we aren't giving you enough help. What is that you say? It's hard?
> It's way harder if we don't give you a roadmap? Well gosh darn, that
> must really suck for you. I'm really sorry that you can't figure it out
> without our help but that's sort of the whole point, isn't it?
1. Is the kernel history locked into bk?
Fact is that exporting the history from bk into a different system
requires extensive scm knowledge, which makes it rather unlikely that a bk
user can do this by himself. He also has various resaons to not ask for
such help, from that he just doesn't care to that he is afraid bk support
might be pulled.
This leaves the other users, which either can't or want to use bk, with
a reduced kernel history (as I have shown in the previous mails). The
practical consequence of this is that a majority of the kernel history is
locked into bk right now, with no way in sight to get it out of there.
2. Larry, do you really thought that kernel hackers have no other
interests than kernel hacking? Do you really thought that all kernel
hackers want to keep the kernel history forever in bk?
I never really wanted to use bk in first place and at that time the
license was annoying but I would have at least used it to push changes to
other bk users. The main reason I don't use bk was and is technical, it
simply doesn't do what I need. The license change just made it completely
unacceptable to even bother. So while I don't care much about bk, I care
of course about the kernel data and only this really sparked my interest
into scm systems. Isn't it ironic that without that license change I
likely wouldn't know as much about scm systems as I do now?
Anyway, if I wanted to write a simple bk clone, I could have done so
already easily without your help, but why should I do so if it's not
what I need in first place? Sorry to disappoint your ego, but the world
doesn't center around bk. Did you know, there are other scm systems out
there? Once one studied a few of them, one basically also knows how bk
works and it certainly helps to put your "facts" into perspective.
Assuming I wrote such a "competing system". What would it change? Could I
or anyone else then import the kernel data into it? How would a user
proceed in order to convert his data, so he can give such a system a real
Well, from your perspective I'm propably already working on a "competing
system", from mine I'm just playing around with some ideas from time to
time, but you certainly keep encouraging me to keep on it and to develop
them into something usable. It's not really a problem to continue using
the bkcvs kernel tree or any other large cvs tree for testing, the bk
data doesn't contain any information I don't know already.
Finally the main question remains (and it will come up over and over
again), how can I or anybody else get my data back out of bk? How can you
claim the kernel history is not property of BM and OTOH the publically
available data is provably not complete? You can continue to use my
interest in scm systems to discredit me as much as you want, but I doubt
we will ever find a suitable candidate, AFAICT anyone only remotely
suggesting using the data in an out of bk context got pretty much the same
treatment from you. Larry, could you please explain, how you exactly
intend to keep the evil scm developers out and at the same time leave
users a choice in their tools once they put their data into bk?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/