From owner-freebsd-current Tue Feb 26 19:31: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0A2A437B400; Tue, 26 Feb 2002 19:31:05 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1R3V3i36837; Tue, 26 Feb 2002 20:31:03 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1R3V2L30560; Tue, 26 Feb 2002 20:31:03 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 26 Feb 2002 20:30:42 -0700 (MST) Message-Id: <20020226.203042.18470792.imp@village.org> To: drosih@rpi.edu Cc: rwatson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms (fwd) From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Garance A Drosihn writes: : I think the main issue here is how long the real repository can be : "locked" while waiting for some change to show up. If work can : keep going into the main repository, then what does anyone care : if someone is tracking their own personal work using CVS, or : perforce, or a bunch of home-grown shell scripts? Apart from Matt, who has encountered this so-called lock? I'm curious, since I haven't seen anybdoy else complaining about it directly. I've not encountered it at all in the stuff I've been working on. There have been a number of recent locking changes go into the tree, for example. There have been times in the past that waiting for a maintainer lock has been worse, but people haven't raised near the stink about that in quite some time. True, most maintainers are responsive, but some are not or go through periods where life happens. All large projects are going to suffer from this problem, not matter the SCM used. p4 is good for some things, bad for others. ditto cvs. However, if the SMPng folks were using a private CVS tree, we'd have similar issues to what we have now (where to get the tree, what package name, etc) with p4. If we do it in the regular FreeBSD, we get lots of repo-bloat as everyone has their own side branch that they MFC stuff into from time to time. It is a no-win situation for people doing large amounts of work, if you want my opinion. The SMPng folks picked a tool that was good for them, and scaled well to the folks that were active in the project. It didn't scale well after a certain point not because it wasn't a good tool, but because people didn't want to learn it (or didn't have the time). I do not believe that p4 is the source of all this evil. People are wrapping too many issues up with it and claiming, falsely in my opinion, that p4 is the root of all evil. I have trouble believing that. Wanrer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message