From owner-freebsd-questions@FreeBSD.ORG Fri Jan 12 00:18:24 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7498D16A407 for ; Fri, 12 Jan 2007 00:18:24 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id E894D13C461 for ; Fri, 12 Jan 2007 00:18:23 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l0C0HpWF026063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jan 2007 02:17:58 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l0C0HW69023740; Fri, 12 Jan 2007 02:17:44 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l0C0HW8V023739; Fri, 12 Jan 2007 02:17:32 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 12 Jan 2007 02:17:32 +0200 From: Giorgos Keramidas To: Doug Hardie Message-ID: <20070112001732.GC23256@kobe.laptop> References: <3C109E4B-5636-498F-A7C2-0C728ED0E81D@lafn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C109E4B-5636-498F-A7C2-0C728ED0E81D@lafn.org> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.475, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.72, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-questions@freebsd.org Subject: Re: Use of CVS X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2007 00:18:24 -0000 On 2007-01-11 11:35, Doug Hardie wrote: > I have a medium sized application where the source is all in a CVS > repository. Basically it works great as I am able to retrieve any > previous version of a module when needed. Most of the changes to the > application are quickly resolved, CVS committed and the production > system updated in less than a day. Recently, I made a fairly large > update to the application that took about 4 weeks to complete. During > that time I was not able to fix small problems as there was no way to > update the production system without incorporating a large number of > changes from the new update that were just not working yet. Basically > all small corrections were made to the new system but not incorporated > into the production system until the new stuff was completed. There > were no real problems from this, but it was not really convenient. > > Now I am going to be embarking on a revision that will take about 6 > months to complete. Obviously I will not be able to wait till the > completion to fix minor problems. So I am going to need to do > something with branches. I have dug through the man pages and believe > that is the best approach. Indeed. Branching and inter-branch merges can be a huge pain in the ass with CVS though. It may be worth investigating if one of the more modern SCM systems -- with better support for merges and merge tracking -- can help you keep the two 'branches' in sync. If you plan to heavily use branches, my personal preference would be Mercurial[1]. It takes a short while to get acquainted with a _distributed_ SCM, if you have been using CVS for a long time, but IMHO the benefits of offline development and excellent merging support (including merge-history tracking, rename tracking, and a few other goodies), far outweighs the cost of migration. [1] http://www.selenic.com/mercurial/ > However, given that I need to maintain the current version with a > probably small number of fixes during the development process what > is the best approach? Should I branch off the production version as > a new branch and keep the main one for the new development or the > other way around. There are two 'models' of work you can use with CVS: * The mainline model. * The promotion model. In the "mainline" model, all development happens in the "HEAD" branch of CVS, and when you are about to release a production version you spin off a 'release branch' off the main trunk of development. In the "feature branch" model, you branch early, and develop features *within* a feature branch. Some time later, these features branches get 'promoted' from feature branch, to testing branch, and eventually to release branch. Which model you will use depends on a lot of factors, not the least of which is how often you will be developing many features in parallel, how long you will have to maintain 'release branches' after you have shipped from them, etc. > Will it be easier to merge the fixes to the production branch back in > to the new system later or should those fixes be made to both branches > at the same time? Any suggestions on these approaches will be > appreciated. In general, with CVS it's a lot easier to use the "mainline" model, where all development happens in HEAD. This doesn't mean that you cannot or that you should not evne consider the "promotion" model of feature branches though. - Giorgos