Re: [ANNOUNCE] BK->CVS (real time mirror)

H. Peter Anvin (hpa@zytor.com)
Wed, 12 Mar 2003 09:29:40 -0800


Dana Lacoste wrote:
> On Wed, 2003-03-12 at 11:13, H. Peter Anvin wrote:
>
>>"Can we get our data out of BK into some kind of open format?"
>
>
>>It's an important question. If the answer is "yes, but only the stuff
>>that can be mapped onto CVS" then that's a significant data loss, and
>>if BitMover changes the data format without documentation, then there
>>is no longer a way to get all the data out.
>
>
> This sounds like the old GPL argument.
>
> The GPL'd redistributor has to supply the source, they don't have to
> supply it in the format that's best for you, being an 80mm tape drive
> cuz you're stuck in the punch card age.
>
> Seriously, if CVS loses all that data, is that BK's fault? BK's so
> powerful because it has more information than anyone else, but it's
> not their fault (and it's not proprietary data) that no-one else can
> deal with the data when it's exported, now is it????
>
> It's not a significant data loss when you try to view a 24bpp image
> on an 8bpp display, so it's not a significant data loss that CVS can't
> handle the BK. If it could, Linus would've switched to CVS instead....
>

You're missing the point completely.

Of course it's not BK's fault that CVS can't represent the data.
However, one of the (valid!) selling points of BK was "we won't hold
your data hostage." That requires that you can export both the data and
the metadata into some kind of open format. Since CVS clearly can't be
that open format (CVS being insufficiently powerful), the additional
metadata needs to be available in some kind of auxilliary form. It's
then, of course, not BK's fault that CVS can't possibly make use of that
auxilliary metadata.

-hpa

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