Date: Sat, 27 Sep 1997 19:48:09 +0200 From: Eivind Eklund <perhaps@yes.no> To: Chuck Robey <chuckr@glue.umd.edu> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, hackers@FreeBSD.ORG Subject: Re: How do I check out a snapshot? Message-ID: <19970927194809.02902@bitbox.follo.net> In-Reply-To: <Pine.BSF.3.96.970928012311.313E-100000@Journey2.mat.net>; from Chuck Robey on Sun, Sep 28, 1997 at 01:27:28AM -0400 References: <19970927191524.23340@bitbox.follo.net> <Pine.BSF.3.96.970928012311.313E-100000@Journey2.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970927194809.02902>