Messages in this thread | | | Date | Sun, 02 Mar 2003 15:12:27 -0500 | From | Jeff Garzik <> | Subject | Re: BitBucket: GPL-ed *notrademarkhere* clone |
| |
Andrea Arcangeli wrote: > your point is purerly theorical at this point in time. bitbucker is so > far from being an efficient exporter that arguing right now about > stopping at the exporter or going ahead to clone it completely is a > totally pointless discussion at this point in time. > > Once it will be a fully functional exporter please raise your point > again, only then it will make sense to discuss your point.
Ok, fair enough ;)
> I'm not even convinced it will become a full exporter if Larry finally > provides the kernel data via an open protocol stored in an open format > as he promised us some week ago, go figure how much I can care what it > will become after it has the readonly capability.
I think this is a fair request.
IMO a good start would be to get BK to export its metadata for each changeset in XML. Once that is accomplished, (a) nobody gives a damn about BK file format, and (b) it is easy to set up an automated, public distribution of XML changesets that can be imported into OpenCM, cvs, or whatever.
>>Let us get this small point out of the way: I agree that GNU CSSC >>cannot read the BitKeeper ChangeSet file, which is a file critical for >>getting the "weave" correct. > > > This is not what I understood from your previous email: > > "BK format"? Not really. Patches have been posted (to lkml, even) to > GNU CSSC which allow it to read SCCS files BK reads and writes. > > Since that already exists, a full BitKeeper clone is IMO a bit silly, > > now you're saying something completely different, you're saying, "yes the > CSSC obviously isn't enough and we _only_ _need_ the exporter but please > don't do more than the exporter or it will waste developement > resources". This is why you changed topic as far as I'm concerned, but > no problem, I'm glad we agree the exporter is useful now.
I am sorry for the misunderstanding then. Let me quote from an email I sent to you yesterday:
A BK exporter is useful.
So I think we do agree :)
>>To me, a "BK clone, read only for now" is vastly different from a "BK >>exporter". The "for now" clearly implies that it will eventually >>attempt to be a full SCM. > > > Why do you care that much now? I can't care less. Period. I need the > exporter and for me the exporter or the bk-clone-read-only is the same > thing, I don't mind if I've to run `bk` or `exportbk` or rsync or > whatever to get the data out. > > If bitbucket will become much better than bitkeeper 100 years from now, > much better than a clone, is something I can't care less at this point > in time, and it may be the best or worst thing it will happen to the > whole SCM open source arena, you can't know, I can't know, nobody can > know at this point in time. > > You agreed the exporter is useful, so we agree, I don't mind what will > happen after the useful thing is avaialble, it's the last of my worries, > and until we reach that point obviously there is no risk to reinvent the > wheel (unless the data become available in a open protocol first).
Yes. As you see, I care about the future and not the present, in my arguments: I believe that a BK clone may hurt the overall [future] effort of creating a good quality open source SCM. So, in my mind I separate the two topics of "BK exporter" and "future BK clone."
To get back to the topic of "BK exporter", I think it is more productive to get Larry to export in an open file format. I will work with him this week to do that. Reading the BK format itself may be interesting to some, but I would rather have BitMover do the work and export in an open file format ;-) Reading BK format directly is "chasing a moving target" in my opinion.
Jeff
- 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/
| |