From owner-freebsd-hackers Tue Oct 14 05:44:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA13780 for hackers-outgoing; Tue, 14 Oct 1997 05:44:20 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA13775 for ; Tue, 14 Oct 1997 05:44:18 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id FAA01733; Tue, 14 Oct 1997 05:44:07 -0700 (MST) From: Terry Lambert Message-Id: <199710141244.FAA01733@usr02.primenet.com> Subject: Re: Large scale code integrations (Was: Re: C2 Trusted To: kpneal@pobox.com (Kevin P. Neal) Date: Tue, 14 Oct 1997 12:44:06 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <1.5.4.32.19971014050321.006e0640@mindspring.com> from "Kevin P. Neal" at Oct 14, 97 01:03:21 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >I don't know if this sort of thing is typical for large changes in > >general, but it does worry me when contemplating them. There just > >seem to be things which can not really be broken up, yet still need > >doing. :\ What is the proper way to go about these, and still have > >something that can be integrated? > > A branch for the changes to go on, and move them over when they are > fully baked? > > Oh joy, more branches. :/ A branch would be one way. It wouldn't let you fix the glaring code layout problems, unfortunately, like config not being built as necessary for kernel configuration changes, or seperation of bus code from architecture code to aid in porting to multiple platforms, etc.. So branch tags are not a panacea; but they'd fix this case... There are still "merge" issues with history files, however. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.