From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29167 invoked by alias); 15 Dec 2002 04:16:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29001 invoked from network); 15 Dec 2002 04:15:06 -0000 Received: from unknown (HELO neon-gw.transmeta.com) (63.209.4.196) by sources.redhat.com with SMTP; 15 Dec 2002 04:15:06 -0000 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id UAA11432; Sat, 14 Dec 2002 20:14:49 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma011428; Sat, 14 Dec 02 20:14:43 -0800 Received: from penguin.transmeta.com (penguin.transmeta.com [10.10.24.137]) by deepthought.transmeta.com (8.11.6/8.11.6) with ESMTP id gBF4EmR08901; Sat, 14 Dec 2002 20:14:48 -0800 (PST) Date: Sat, 14 Dec 2002 21:34:00 -0000 From: Linus Torvalds To: neroden@twcny.rr.com, Subject: Re: source mgt. requirements solicitation In-Reply-To: <20021215014255.GA1146@doctormoo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-12/txt/msg00819.txt.bz2 In article <20021215014255.GA1146@doctormoo> you write: > >In GCC, we've been known to lose development history when we merge a >branch, and merging branches has been incredibly painful. So I'm not >sure merging forks is actually harder; merging branches may be. ;-) Heh. That's a sad statement about CVS branches in itself. >Fork merges get submitted as a series of patches (which then need to get >approved), and associated ChangeLog entries. They go in pretty cleanly. This is actually not that different from the "old" Linux way, ie the SCM does _nothing_ for merging stuff. It certainly worked fine for me, and it's how about half of the Linux developers still work. The advantage of the SCM-assisted merges is really that when you trust the other side, it becomes a non-issue. So to some degree you might as well think of a SCM-assisted merge as having "write access" to the tree, except it's a one-time event rather than a continuing process (but unlike CVS write access it doesn't _need_ to be constant, since both sides have access to their own SCM structures on their own, and don't need to merge all the time). >The fork developer can track his/her own internal change history however >he or she likes, but generally will submit an 'expurgated' history for >merging, devoid of the false starts, which makes the patches a lot easier >to review. This is in fact an argument in favor of losing >development history. ;-D We do that with BK too, occasionally. It's sometimes just cleaner to create a new clone with a "cleaned up" revision history. It's not needed all that often, but I certainly agree that sometimes you just don't want to see all the mistakes people initially made. It's also needed in BK for things like merging from two totally different repositories - you can't auto-merge just one fix from a Linux-2.4.x BK tree into a 2.5.x BK tree, for example (when you merge in BK, you merge _everything_ in the two repositories). So those have to be done as patches, kind of like the clean-up thing. >>Yet it is the _cheap_ branches that should be the true first-class >>citizen. Potentially throw-away code that may end up being really >>really useful, but might just be a crazy pipe-dream. The experimental >>stuff that would _really_ want to have nice source control. > >Interestingly, I tend to find that this sort of stuff is exactly what >*doesn't* need source control; source control simply obscures the >process by exposing too much development history, much of which has no >relevance to the current version. Or did you mean code that already >works, and is being refined, rather than code in the 'rewrite from >scratch every two weeks' stage? I personally find that _most_ changes by far tend to be fairly small and simple, and take a few hours or days to do. Yet at the same time, you want to have access to a lot of the SCM functionality (commit one set of changes as "phase 1 - preparation", "phase 2 - update filesystems" etc). At the same time, the tree often doesn't work until all phases are done, so you do NOT want to commit "phase 1" to the CVS head - and creating a CVS branch for something that is really not a big project is clearly not something most people want to do. The pain of the branch is bigger than it's worth. And THIS is where the distributed repository nature of BK really shines. It's a totally everyday thing, not something odd or special. You can work in your own repository, with all the SCM tools, and document your changes as you make them (and undo something if you notice it was wrong). Yet you do _not_ need to pollute anything that somebody else might be working on. And then, when you're ready, you just push your changes to some other tree (in BK it's an atomic operation to push _multiple_ changesets), and tell others that you're done. See? I'm not talking about a big six-month project. I'm talking about something that potentially is just a few hours. You might do your first cut, and check it into your tree, verify that it works, and then you might want to go back and make another few check-ins to handle other cases. In gcc terms, let's say that you change the layout of something fundamental, and you first make sure that the C front-end works. You check that in and test it (on the C side only) as one stage. Only when you're happy with that do you even _bother_ to start editing the C++ and other front-ends. With distributed trees, it's easy to make these kinds of multi-stage things. Because nobody else sees what you're doing until you actually decide to export the thing. With CVS, it's a total _disaster_ to do this (and the way everybody works is to do all the work _without_ SCM support, and then try to do one large check-in). Linus