From owner-freebsd-hackers Sat Sep 27 10:48:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04308 for hackers-outgoing; Sat, 27 Sep 1997 10:48:21 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA04297 for ; Sat, 27 Sep 1997 10:48:16 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id TAA12207; Sat, 27 Sep 1997 19:48:09 +0200 (MET DST) Message-ID: <19970927194809.02902@bitbox.follo.net> Date: Sat, 27 Sep 1997 19:48:09 +0200 From: Eivind Eklund To: Chuck Robey Cc: "Jordan K. Hubbard" , hackers@FreeBSD.ORG Subject: Re: How do I check out a snapshot? References: <19970927191524.23340@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69e In-Reply-To: ; from Chuck Robey on Sun, Sep 28, 1997 at 01:27:28AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 28, 1997 at 01:27:28AM -0400, Chuck Robey wrote: > On Sat, 27 Sep 1997, Eivind Eklund wrote: > > This should be irrelevant for adding CVS tags for each commit, I > > believe. It will increase the ctm delta size a little, but the ctm > > deltas would still only refer to files that are modified anyway. (At > > least that was an expense I knew about - I'm just wondering if there > > is some hidden expense I _don't_ know about, like files with a huge > > number of tags being excedingly slow to work with, or somesuch.) > > You were talking about tagging the entire tree, right? No. I was talking about adding tags to each commit to serialize them (making a single commit share a property that is easy to manipulate, instead of just sharing the commit message), and using tags to indicate how merges have been done, to simplify (more-or-less automate) later merges. Merges should be possible to make as easy as this: # Merge commit #1498 to the RELENG_2_2 branch cvs merge COMMIT1498 to RELENG_2_2 # Merge all new commits to ppp from HEAD to RELENG_2_2, as a single # commit cvs merge all from HEAD to RELENG_2_2 block # Merge all commits to ppp from HEAD to RELENG_2_2, as a series of # commits with the same log messages with prefix "MFC: " cvs merge all from HEAD to RELENG_2_2 serialized prefix "MFC: " # Merge all changes from the HEAD to the present directory (have to be # as a block) cvs merge all from HEAD to . I'm not certain all of this is feasible within the CVS "database structure" but I've been toying with the idea of implementing some of this based on meta-information in non-moving tags, with cvs merge replaced by an external cvsmerge script. If tags to the files you're modifying anyway are cheap, serializing the commits is something that could be started more or less right away. If it is expensive - well, then I need to find another solution, possibly abandoning CVS in the process. This would have good and bad sides; the worst one is that this is such a large project that I'd be much less likely to implement it ;-) Eivind.