lkml.org 
[lkml]   [2003]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] BK->CVS (real time mirror)
[ hoping this is the last email in this thread, I know I'm not
contributing to this reach this objective :) ]

On Sun, Mar 16, 2003 at 08:33:18PM +0100, Roman Zippel wrote:
> Hi,
>
> On Sun, 16 Mar 2003, Nicolas Pitre wrote:
>
> > > The missing bits are absolutely not worthless. They are very useful when
> > > you want to test other SCM system to simulate distributed development.
> >
> > This is completely ridiculous. Isn't this a bit too demanding?
>
> Not really, it's actually more simple to what Larry is currently offering.
> easy to add as well. If you now also add a sequence number is quite simple
> to modify a CVS server which can export the data reliably.

CVS basically exports RCS through the network, your argument makes no
sense to me, what's the difference, I don't see what you mean.

> > Be realistic. The missing bits are worthless and add absolutely no value to
> > kernel development which is supposed to be the topic for this mailing list.
>
> If you want to test an alternative system to see whether it's usable for
> kernel development, what better data is there? How could you compare it
> against bk?

Larry has all the rights to not to help providing a testcase, it makes
no sense for you to complain he's not providing a testcase for a
competitive system. It make no sense just like complaining that if Larry
changes the bk format to something encrypted compressed or .doc. he has
the rights to do it, so please stop raising pointless arguments.

You could make a bit more of sense if your argument was that you still
miss the visibility on the jfs developement or similar, but the fact a
"testcase" for a competitive SCM this way is missing makes no sense at
all. Infact a much testcase is not missing! just give us the alternative
open SCM and we'll be glad to try using it in real life, which is an
order of magnitude better testcase than feeding the old data into the
repository offline.

If you're still unhappy now that the mainline data is open it means
you're either a jfs developer (but I assume they're all fine with bk
since they're just using it, so I doubt this is the case) or your
problem is that you don't like the fact that Linux is still developed
with proprietary software but in such case go speak with Linus not with
Larry.

From my part - now that the full data and metadata of the main branch is
available in the open in a usable form - I have no problem anymore with
Linus using bitkeeper. I'm not religious about Linux, I'm only religious
about my freedom. Sure, now I would like if Linus and Marcelo would be
the only one using bitkeeper (so CVS would miss zero info), yes, but
really all other branches are of nearly zero interest to me compared to
the main branch and usually important branches like the jfs one (I don't
know the others since I can't see them, I only know the jfs one because
it gave me troubles with bkweb, this is why I'm only mentioning such
one) can be retrieved via other methods (like asking the developers by
emails).

Now I need to write tools to extract the stuff and parse it with more
intelligent software than CVS, one of those tools is just available, so
please stop these complains, and help writing a reliable changelog
extractor using the dates and verifying the stuff with the logic tag. It
doesn't matter if the CVS protocol is good or bad, as far as the whole
mainline kernel evolution data is available reliably in the open, so
from my part I'm extremely happy because I finally have a chance to
start appreciating the advantages of Linus and Marcelo using bitkeeper ;)

Andrea
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.106 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site