Date: Tue, 26 Feb 2002 19:06:25 -0800 From: Peter Wemm <peter@wemm.org> To: David Greenman <dg@root.com> Cc: Robert Watson <rwatson@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) Message-ID: <20020227030625.2772939F1@overcee.wemm.org> In-Reply-To: <20020226184654.B21520@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > >In the past week, a number of comments have been made both for and against > >additional version control mechanisms being used to supplement the FreeBSD > >Project official CVS server. Proponents of additional mechanisms, such as > > It's my view that work that happens outside of our official CVS repo is > private work no matter what source control system is used (or if one is used > at all). It is always a problem for one developer to say "I've got changes to > <whatever>, so don't touch that part of the system." This might be justified > for a very short period (measured in a few days at most), but anything longer > term will almost certainly put off other developers that may wish to work > in the same or related area. > This isn't a new problem, either. We've had similar turf conflicts before > that very much resembled the one at hand. So...What's that phrase? - "Either > take a dump or get off the pot". Something like that. Developers need to > develop in ways that their work gets out as soon as possible so that 1) Other > developers can review the work as it happens, make comments - perhaps > influencing the design at an early stage when it really needs to be, and > 2) So that you don't end up with some buggy mega-commit that has so much > stuff wound up in it that it's nearly impossible to isolate the bugs. > Anyway, my point is that the Perforce repo itself isn't the problem. The > problem is that people are maintaining private patch sets for long periods > and making claims to the areas that their patches cover. Step-wise evolution > is the only way to go in this distributed development model and in order to > acheive this, private development trees need to be minimized as much as > possible. Some things are too impractically large to do incrementally and are an all-or-nothing thing. I recall seeing your early VM commits which were huge, you had been working on for months, and were not incremental things. I'm not taking sides on what has been done offline in the current fights with this statement, but I do take issue with statements that everything can and should be done incrementally. Take the sparc64 stuff. For quite some time, they had hacks in the generic PCI code that was deemed unacceptable to the rest of the platforms. The trick to things working smoothly is to not overuse stuff out of the cvs tree. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020227030625.2772939F1>