From owner-freebsd-hackers@FreeBSD.ORG Wed May 14 23:39:39 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDD6E106566B for ; Wed, 14 May 2008 23:39:39 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: from episec.com (episec.com [69.55.237.141]) by mx1.freebsd.org (Postfix) with SMTP id AD9708FC14 for ; Wed, 14 May 2008 23:39:39 +0000 (UTC) (envelope-from edelkind-freebsd-hackers@episec.com) Received: (qmail 54832 invoked by uid 1024); 14 May 2008 23:12:58 -0000 Date: Wed, 14 May 2008 19:12:58 -0400 From: ari edelkind To: freebsd-hackers@freebsd.org Message-ID: <20080514231258.GB79355@episec.com> Mail-Followup-To: ari edelkind , freebsd-hackers@freebsd.org References: <482B5E08.9000309@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <482B5E08.9000309@icyb.net.ua> Subject: Re: using git for freebsd development X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 23:39:39 -0000 avg@icyb.net.ua wrote: > The following can be considered as a followup to the excellent > FreeBSD/GIT wiki page: > http://wiki.freebsd.org/GitConversion > [...] > All of the tools either required source CVS repository to be available > locally or worked much faster in that case, so the first thing to do was > to get src-all from my local cvsup mirror. Easy. Everyone who tries converting freebsd's cvs repository to joe-random-RCS attempts to import the entire source tree as a single project. Honestly, it covers too broad a spectrum. Separate these projects into the cvsup collections: src-sys, src-bin, src-lib, etc.. You won't be able to simply tag a single branch into a full system release without a wrapper script to handle your collections, but that's a small price to pay for the added robustness, separation of privilege, and smaller-scale potential for conflict. In fact, even src-bin may be too broad, and it may make sense to have separate projects within the collection hierarchy. This would, at least, make reparenting projects (say, from src-bin to src-usrbin) easier. ari