From owner-freebsd-hackers Tue Aug 6 10:51:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03486 for hackers-outgoing; Tue, 6 Aug 1996 10:51:58 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA03481 for ; Tue, 6 Aug 1996 10:51:56 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id KAA03376 for ; Tue, 6 Aug 1996 10:51:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA13596; Tue, 6 Aug 1996 10:47:26 -0700 From: Terry Lambert Message-Id: <199608061747.KAA13596@phaeton.artisoft.com> Subject: Re: Announcing CVSup: Intelligent SUP Replacement To: jdp@polstra.com (John Polstra) Date: Tue, 6 Aug 1996 10:47:26 -0700 (MST) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199608060231.TAA18672@austin.polstra.com> from "John Polstra" at Aug 5, 96 07:31:02 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-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 4. Meanwhile, run CVSup whenever you want to. New deltas will come in, > but they won't interfere with your stuff. [ ... ] > Ick, not very nice. It's the same problem that led to the demise > of the -stable branch. The merges get awkward pretty fast. It > might be a bit easier if you made clever use of a couple of additional > tags, to keep track of where you did your last merges from on the > main branch. [ ... yes; I'd assumed tags would be involved ... ] My main concern was: 1) get main line tree 2) make local changes on tag A 3) make local change on tag B that depend on those in tag A 4) local changes in tag A get committed to main line tree, but they are not exactly the same. A is now a dead local tag. 5) get new main line code 6) merge changes from tag B The problems seem to be: a) partial merge of tag A changes b) merge with tag B after A commit conflicts (can't be avoided, I suppose) c) getting a local tree that can be built (mostly a problem if I have a bunch of tags ans want to keep them seperate) This last one is more like: Getting from: To: Main o---->o tag A Main + A o---->o tag B | | | | | v | v | o tag B | o tag C | | | | v v | o tag C o | v o tag A integrated This is exactly the situation I have, were I need to break a lot of work into parts that can be trivially code reviewed without losing the ability to get a local tree with the main line changes as they go along. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.