From owner-freebsd-stable Mon Oct 26 11:21:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10930 for freebsd-stable-outgoing; Mon, 26 Oct 1998 11:21:55 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10925 for ; Mon, 26 Oct 1998 11:21:52 -0800 (PST) (envelope-from rkw@Dataplex.NET) From: rkw@Dataplex.NET Received: from dataplex.net (nomad.dataplex.net [208.2.87.8]) by shrimp.dataplex.net (8.9.1/8.9.1) with ESMTP id RAA19616; Mon, 26 Oct 1998 17:38:27 -0600 (CST) (envelope-from rkw@dataplex.net) Message-Id: <199810262338.RAA19616@shrimp.dataplex.net> Date: Mon, 26 Oct 1998 13:20:49 -0600 (CST) Subject: Re: CTM Release Generation - (Re: Stable and CTM) To: luigi@labinfo.iet.unipi.it cc: freebsd-stable@FreeBSD.ORG In-Reply-To: <199810261308.OAA02338@labinfo.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26 Oct, Luigi Rizzo wrote: > i am just jumping in on the middle of a discussion so apologies if i > say stupid things... but isn't everything one needs in the CVS > repository so _in theory_ at least one could ask cvs, file by file, to > produce the differences without having to replicate things ? And, being > things stored in cvs, the deltas from one version to the other of the > same file are stored in a reasonable compact way... The fundamental problem is "_in theory_". In practice, the master CVS tree gets yanked around from time to time. AFAIK, the only way to be certain that you have a correct copy of the tree, as distributed by CTM, is to generate it by actually applying the CTM deltas. As for a shortcut to generating the deltas, I would be more inclined to snoop on a cvsup session and capture a list of files which need attention. You would still need to periodically run a full comparison to make sure that nothing fell through the cracks. The real hangup in the whole process is related to the inefficient way that our sources are stored in single tree. In order to get to the recent 2.2 tree, you have to back out a whole lot of changes to "current" to get back to the branch point and then put many of them back in when you return up the 2.2 history track. I know that the would be more efficient to have a separate tree for tracking 2.2. I also suspect that it would require little extra HD space. The other advantage would be that the old history on the bottom of the rcs files could be removed and stored on a read-only area which chains from the current file. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message