Date: 20 Feb 1996 09:25:33 -0600 From: "Richard Wackerbarth" <rkw@dataplex.net> To: "jkh@time.cdrom.com" <jkh@time.cdrom.com>, "Satoshi Asami" <asami@cs.berkeley.edu> Cc: "current@FreeBSD.org" <current@FreeBSD.org> Subject: Re(2) I'd vote to put the CVS repository onto the next FreeBSD CD-Rom Message-ID: <n1387314148.8028@Richard Wackerbarth>
next in thread | raw e-mail | index | archive | help
Earlier Jordan wrote: > * But I might be able to squeeze it onto the first CD someplace. I'd * > also like to put the CTM base deltas there, somehow. On 2/20/96 at 12:44:57 PM Satoshi Asami wrote: > Do you think it's possible to replace srcdist with cvsdist? Then it wouldn't take much more space. >Basically, we need a "tarcvs" that we can use like "cat cvs*.?? | gunzip |tarcvs -input - -subdir share -command co -rRELENG_2_1_3" Yes, this kind of capability would make a good project. As I see it, one problem that we have is the proliferation of various forms of basically the same material. I think that we need to address two aspects of this. 1) We need to have a reasonable scheme to allow the various forms to peacefully coexist. This means, for example, that NONE of them exists in /usr/src. If a user must place source in /usr/src, that should be done by making a copy, either real or virtual. In other words, he "installs" the source from the true location. 2) We need to reduce the various forms for the distribution of the same material. In particular, I see no reason to have "tarballs" of the source and ctm base deltas. Why not simply use the ctm format for both purposes? As I see it, we will need to have four trees. A) The cvs tree. Unless we have an "inexpensive" way to derive the other trees from this (and I don't see that), it is a separate tree. B) The "current" tree. C) The tree associated with the release CD. D) The "stable" tree. I do not think that (C) and (D) are, in general, the same. (C) is basically a candidate for "stable". However, (B), (C), and (D) will, in general, have a large portion of common code. Instead of "tarballs" of the source, we can produce CTM base files. If you wish to download the source, you get a base file and, perhaps, an update file. You use ctm to unpack them. There is one thing that we would have to change from the current scheme. We can easily generate a group of initial ctm files so that someone can get only a portion of the source tree rather than the whole tree. However, I do not consider it practical to have a large number of update paths. Therefore, ctm needs to be modified to recognize and ignore intentionally missing subtrees. I think we can do this by expanding the .ctm_status file to be a directory of subdistribution status files. Each status file would give the latest update installed and the first update that was omitted. That way, one could go back, retrieve the additional files and re-apply them to add a previously omitted subtree. If people think this is a workable approach, I'll modify ctm to implement it. Richard Wackerbarth rkw@dataplex.net Sent with a test-drive version of CTM PowerMail 1.0.6 <http://www.ctm.ch>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n1387314148.8028>