Messages in this thread | | | Date | Sun, 14 Dec 2003 15:17:04 -0800 | From | Tupshin Harper <> | Subject | Re: RFC - tarball/patch server in BitKeeper |
| |
Larry McVoy wrote:
>Merry Christmas. > >I've prototyped an extension to BitKeeper that provides tarballs >and patches. The idea is to make it possible for all trees hosted by >bkbits.net provide access to the data with a free client (included below >in prototype form). > >The system is simplistic, it just provides a way to get the most recent >sources as a tarball and then any later updates as a patch. There is >no provision for generating diffs, editing files, merging, etc. All of >that is something that you can write, if you want, using standard tools >(think hard linked trees). > >Before rolling this out, I want to know if this is going to (finally) >put to rest any complaints about BK not being open source, available on >all platforms, etc. You need to understand that this is all you get, >we're not going to extend this so you can do anything but track the most >recent sources accurately. No diffs. No getting anything but the most >recent version. No revision history. > >If you want anything other than the most recent version your choices >are to use BitKeeper itself or, if you want the main branches of the >Linux kernel, the BK2CVS exports. This is not a gateway product, it >is a way for developers to track the latest and greatest with a free >(source based) client. It is not a way to convert BK repos to $SCM. > >If the overwhelming response is positive then I'll add this to the >bkbits.net server and perhaps eventually to the BK product itself. > >--lm > I'm sure many people will find this useful. Personally (and this is not intended as any sort of flame bait), I just want a way to get access to all raw bk changesets for a given project. All existing methods of getting information out of a bk repository either involve running bk yourself, or getting incomplete information. You have argued (succesfully) that the CVS export doesn't lose very much information, but an argument can be made that any information loss is too much. After all, the information I am talking about is simply what was put into the system by the developers in the first place.
-Tupshin - 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/
| |