From owner-freebsd-hackers Mon May 15 19:15: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id CA36C37B91C for ; Mon, 15 May 2000 19:15:03 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA271786; Mon, 15 May 2000 22:14:58 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200005151956.NAA39443@harmony.village.org> References: <200005151956.NAA39443@harmony.village.org> Date: Mon, 15 May 2000 22:14:50 -0400 To: Warner Losh , hackers@FreeBSD.ORG From: Garance A Drosihn Subject: Re: CVS question Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:56 PM -0600 5/15/00, Warner Losh wrote: >I have a CVS question. Normally I wouldn't bother the nice folks here >with it, but since it involves backmigrating the local changes Timing >Solutions has made to FreeBSD, I thought that others might find its >answer useful in the future. I would be interested, for one... :-) >We have a CVS repo that we import the FreeBSD sources into from time >to time. All FreeBSD sources are kept on a repo branch. [...] > >Some of the changes that we've made won't be merged into FreeBSD as >they are rather hackish in nature [...]. Most of them will. As they >migrate back into FreeBSD, we also need to put them back on the vendor >branch, which I've done in the past by doing an import and changing >the branch rev from 1 to 1.1.1 with cvs admin, so that's covered. > >Other than using perforce, can anybody recomment a good way to manage >this situation? Somewhere recently I was reading about an alternate version of cvs which had the idea of cvs repository hierarchies. I *think* it was 'rcvs' (Renegade CVS) which I tripped over at sourceforge, but when I went back to read more on it I couldn't find whatever writeup I had remembered. Since I only read one time, I may have some details mixed up. It was something like you check out a local repository from the main repository. The local developers check things in-and-out of the local repository, and when everyone's happy with it you can 'commit' changes from the local repository back into the repository it came from. I think this 'commit' step required that the local repository included all changes already in it's parent repository, so any conflicts between repository's had to be resolved at the local repository. I don't know if that was actually implemented, or just a blue-sky idea of something they hoped to do. I do know I'd like to do something pretty similar to what you're talking about, and would like to have a good way to keep track of all the pieces. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message