From owner-freebsd-hackers Sat Apr 19 08:29:33 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA22108 for hackers-outgoing; Sat, 19 Apr 1997 08:29:33 -0700 (PDT) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA22097 for ; Sat, 19 Apr 1997 08:29:23 -0700 (PDT) Received: (from eivind@localhost) by nic.follonett.no (8.8.5/8.8.3) id RAA26899; Sat, 19 Apr 1997 17:26:14 +0200 (MET DST) From: Eivind Eklund Message-Id: <199704191526.RAA26899@nic.follonett.no> Subject: Re: CVS vendor branches To: terry@lambert.org (Terry Lambert) Date: Sat, 19 Apr 1997 17:26:14 +0200 (MET DST) Cc: hackers@freebsd.org In-Reply-To: <199704182251.PAA03213@phaeton.artisoft.com> from Terry Lambert at "Apr 18, 97 03:51:31 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > a way of hacking some of the wanted > > features is by treatingthe FreeBSD main development as a vendor > > branch, and using cvs import to maintain the parts you don't change. > > This works, but then I have my history at the cost of losing that > of FreeBSD. It also leaves the issue of integrating my history > blowing in the wind... when/if an integration takes place, the > only thing imported will be my tip, right? So if I do something to > accommodat a VM bug (say), and it's later fixed, and I want to > branch back there for maintenance, now you must resolve conflicting > tips, right? Not nescessarily. I have some ideas for how to create a fake branch at your machine, and then importing the branch into the FreeBSD CVS repository _as a branch_ at a later date. (1) You work on a CVS-tree with FreeBSD-current imported as a base. Any conflicting changes to the tree done by the main FreeBSD development line, you merge. (This is less work than it sound like). When you're done, you end up with one large patch which will bring -CURRENT to be equal to your source (or the relevant parts of it). You submit this as a script, a script which also recreate your changes as a branch of the FreeBSD CVS tree. This way, your editing history will be recorded in a branch, and the tip of that branch will be integrated as YAMFT with a reference to your branch for editing history. At this point, you abandon your changes to the imported source, as your changes have been brought into the main tree. (The abandoning can be done by re-creating the underlying CVS/RCS files of just those files, if nescessary re-creating any later patches. This can be automated.) If you are doing further development, you create another branch. Diskspace requirements: This model would require a FreeBSD CVS tree kept up to date, a copy of the FreeBSD source tree used as an import base, a local CVS tree with the imported sources, and a checked out copy of the FreeBSD sources with your changes from the local CVS tree. (2) This could probably also be done by creating a copy of the FreeBSD CVS tree with a "Terry" branch in it. You would need to create a local copy of the FreeBSD CVS tree, branch it, and make scripts to keep the head up to date with regards to a clean copy. It is possible that all of this could be done from the CTM delta files. Integration of your changes and edit-history would have to be done in the same way as suggestion (1). Benefits of (1) is that it is least work to implement; benefits of (2) is that it is probably most comfortable to work with. Does the above suggestions sound like it could create a tolerable working-environment? As for the 'ideal environment' section: I'm having a difficult time envisioning how your 'unbranching' would work; any changes will need to be merged by a human at some point, and I can't see how unbranching would work differently from the present branches, except that they presumably have a machine-readable tag pointing back from the merge-point, and are frozen at merge. This sound technically sound, but not really nescessary. Am I missing something? Having CVSup/CTM automatically create and rename branches sound nice; I wonder how much work it would be to implement. However, just having them respect branches would probably be enough; the problem is how to do this and still keep CVSup as rock-solid as it is towards partial or damaged CVS-trees. regards, Eivind.