From owner-freebsd-current Sun May 4 11:22:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA08749 for current-outgoing; Sun, 4 May 1997 11:22:22 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA08744 for ; Sun, 4 May 1997 11:22:20 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14228; Sun, 4 May 1997 11:20:07 -0700 From: Terry Lambert Message-Id: <199705041820.LAA14228@phaeton.artisoft.com> Subject: Re: Help with merging in local changes with CVS etc... To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 4 May 1997 11:20:07 -0700 (MST) Cc: current@FreeBSD.ORG, joes@spiritone.com In-Reply-To: <19970504174407.EZ62108@uriah.heep.sax.de> from "J Wunsch" at May 4, 97 05:44:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I know I will need to maintain a copy of the full CVS repository, but > > how do I ensure that the change will remain in effect after further > > changes (pulled in with CVSup)? > > Are you sure you really want to check it into your CVS? I think the > cvsup documentation in the handbook mentions how this would to be > done, though i'm not familiar with it either. It involves a FreeBSD committer providing a branch tag for local use by the committer -- one tag per thread of changes. It don't provide a mechansim for coelescing the tag head when you finally accept the changes for commit. It doesn't provide a history merge mechanism (which would rely on the coelese) so that if a change that impacted the post-merge code needed to be backed out (say a VM change or dimilar dependency), then the post-backout would no longer function. > If you just apply the modifications to your tree, subsequent `cvs > update' operations will try its best to maintain your local changes > to the checked out tree. It won't always be successful, so you should be prepared to resolve conflicts manually. Because of this, you must manually do the updates, and resolve before subsequent updates. This means that it's impossible to automate the process. It also mens that you can't locally maintain history for your code in your local tree (ideally, you would track colliding changes so that you could back the colliding tree out to whatever revision you wanted, and your merged code would still function; no dice with the suggested method). > I think i've got some 20+ files in my kernel source tree that > differ from the official versions, and a few files outside the kernel. > I sometimes commit the changes once they `matured' (see the syslogd > commit yesterday), sometimes i don't commit them since they are > unclean and need more work, some of the changes are purely local > (e.g. i've totally ripped off rm'ing the old compile directory from > config(8) since bothered me once too many). You are in a different boat. You can commit changes to the main tree and get them communicated to your local copy of the tree that way. It won't work for people who don't have commit priveledges to the main tree, only to their copy of the main tree. CVS is barely adequate. 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.