Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Mar 2003 08:42:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Mar 2003 08:42:22 -0500 Received: from bjl1.jlokier.co.uk ([81.29.64.88]:8320 "EHLO bjl1.jlokier.co.uk") by vger.kernel.org with ESMTP id ; Mon, 10 Mar 2003 08:42:21 -0500 Date: Mon, 10 Mar 2003 13:52:48 +0000 From: Jamie Lokier To: Horst von Brand Cc: Zack Brown , Larry McVoy , linux-kernel@vger.kernel.org Subject: Re: BitBucket: GPL-ed KitBeeper clone Message-ID: <20030310135248.GA12232@bjl1.jlokier.co.uk> References: <20030309024522.GA25121@renegade> <200303100341.h2A3fKEO004164@eeyore.valparaiso.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303100341.h2A3fKEO004164@eeyore.valparaiso.cl> User-Agent: Mutt/1.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1778 Lines: 36 Horst von Brand wrote: > Zack Brown said: > > I'd be willing to maintain this as the beginning of a feature list and > > post it regularly to lkml if enough people feel it would be useful and not > > annoying. The goal would be to identify the features/problems that would > > need to be handled by a kernel-ready version control system. > > I believe that has very little relevance to lkml, only perhaps to a mailing > list for a bk replacement. For the kernel this work has already been done > (by Larry and the head penguins). I'd like to thank those kind souls who explained how branch _and_ merge history is used by the better merging utilities. Now I see why tracking merge history is so helpful. (Tracking it for credit and blame history was obvious, but tracking it to enable tools to be better at resolving conflicts was not something I'd thought of). Of course there will be times when two or more people apply a patch without the history of that patch being tracked, and then try to merge both changes - any version control system should handle that as gracefully as it can. However I now see how much actively tracking the history of those operations can help tools to reduce the amount of human effort required to combine changes from different places. So thank you for illustrating that. ps. Yes I know that CVS sucks at these things. I've seen _awful_ software engineering disasters due to the difficulty of tracking different lines of development through CVS, first hand :) -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/