From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Robert Anderson Newsgroups: gmane.emacs.devel Subject: Re: gratuitous changes Date: 03 Feb 2003 08:20:34 -0800 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1044289234.6248.42.camel@lan1> References: <200301312148.h0VLmG128712@rum.cs.yale.edu> <20030131235443.F7B7.LEKTU@terra.es><1044082289.14974.15.camel@lan1> <200302031509.h13F9oc11594@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1044289230 5534 80.91.224.249 (3 Feb 2003 16:20:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 3 Feb 2003 16:20:30 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18fjKd-0001R0-00 for ; Mon, 03 Feb 2003 17:20:27 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18fjSI-0000xt-00 for ; Mon, 03 Feb 2003 17:28:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18fjKX-000834-00 for emacs-devel@quimby.gnus.org; Mon, 03 Feb 2003 11:20:21 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18fjJw-0007uM-00 for emacs-devel@gnu.org; Mon, 03 Feb 2003 11:19:44 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18fjIz-0007Km-00 for emacs-devel@gnu.org; Mon, 03 Feb 2003 11:18:46 -0500 Original-Received: from adsl-63-207-14-122.dsl.snfc21.pacbell.net ([63.207.14.122] helo=localhost.localdomain) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18fjHY-0006nf-00 for emacs-devel@gnu.org; Mon, 03 Feb 2003 11:17:16 -0500 Original-Received: from lan1 (lan1 [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h13GKYPM006828; Mon, 3 Feb 2003 08:20:34 -0800 Original-To: Stefan Monnier In-Reply-To: <200302031509.h13F9oc11594@rum.cs.yale.edu> X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11323 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11323 On Mon, 2003-02-03 at 07:09, Stefan Monnier wrote: > > > Stefan "about 200 locally modified files" > > PS. You need a branch about 190 files ago. :) > > A sandbox is in many ways a special extra-leightweight branch, > and I do use it that way (I have a couple other sandboxes). Sure. But editing 200 files is a bit of a heavy lifting task for an extra-lightweight branch without the features to control those kinds of extensive changes. > A real branch would have the advantage of making the code available to > other people, That's one advantage, but probably not the central one from my view. The central advantage is that I have serious doubts that your 200 changed files comprise one well-defined changeset that fixes bug X or adds feature Y. Even if it does implement some kind of large feature or bugfix, I think if upon commit, a regression or crashing bug was discovered, you would have quite a large number of possibilities of where to look for the bug, and, the real problems with large-scale development in a sandbox - no way of recreating the intermediate steps you used to get to the code state that was committed. If instead you had a branch, you could approach your tasks one at a time without fear of disturbing other developers when it is time to check in a tentative or intermediate logical changeset. Why do logical changesets matter? 1) Because they can be rolled back when bugs appear to isolate the possible causes, creating ostensibly self-consistent code states at each step, as opposed to rolling back a file and just hoping the changes in that file don't depend on other changes in other files. 2) Because it is often the case that branch developers will want to incorporate some changes from mainline or vice-versa in order to do their own work more effectively, and doing so with logical changesets has an order of magnitude less complexity than trying to do so an a per-file basis. Not to mention that CVS's complete lack of history sensitivity for merging makes this a dangerous and confusing task from the get-go - probably best avoided altogether, which is a shame. but requires more work when merging changes from the > trunk, when committing changes to the trunk and it would be more > difficult to get a meaningful summary of "what's changed w.r.t. the > trunk" which I normally have all the time in my *cvs* buffer. Right. Because CVS branch support is abysmal, for no good reason other than historical baggage. > I guess there is something for CVS, Subversion, MetaCVS, Arch, OpenCM, ... > to learn here, but I'm not sure what, Seamless support for branches is central. Arch, for one, nails this. (But neither is it demonstrably ready for prime-time deployment). Stepping off soap box, Bob