Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 27 Dec 2001 16:40:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 27 Dec 2001 16:40:04 -0500 Received: from bitmover.com ([192.132.92.2]:43422 "EHLO bitmover.bitmover.com") by vger.kernel.org with ESMTP id ; Thu, 27 Dec 2001 16:39:52 -0500 Date: Thu, 27 Dec 2001 13:39:51 -0800 From: Larry McVoy To: Dana Lacoste Cc: "'Larry McVoy'" , linux-kernel@vger.kernel.org Subject: BK stuff [was Re: The direction linux is taking] Message-ID: <20011227133951.M25698@work.bitmover.com> Mail-Followup-To: Dana Lacoste , 'Larry McVoy' , linux-kernel@vger.kernel.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from dana.lacoste@peregrine.com on Thu, Dec 27, 2001 at 01:24:27PM -0800 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org My apologies to the list if this is considered off topic. I changed the subject so you can kill this thread if you like. I know how popular BK discussions are :-) On Thu, Dec 27, 2001 at 01:24:27PM -0800, Dana Lacoste wrote: > Mostly playing devil's advocate here :) > > > Merging is much easier. > > how exactly? It's probably an off topic conversation, but in the interesting case (i.e., it won't patch cleanly), both text based and GUI based tools are available to help with the merge. They are better than anything you're used to or I'll eat my hat. For example, if you are a CVS user, you are used to this: <<<<<<< local slib.c 1.645 sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj); assert(HASGRAPH(sc)); sccs_sdelta(sc, sccs_ino(sc), file); <<<<<<< remote slib.c 1.642.2.1 sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p); assert(sc->tree); sccs_sdelta(sc, sc->tree, file); >>>>>>> but we can give you this: <<<<<<< local slib.c 1.642.1.6 vs 1.645 sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj); - assert(sc->tree); - sccs_sdelta(sc, sc->tree, file); + assert(HASGRAPH(sc)); + sccs_sdelta(sc, sccs_ino(sc), file); <<<<<<< remote slib.c 1.642.1.6 vs 1.642.2.1 - sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj); + sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p); assert(sc->tree); sccs_sdelta(sc, sc->tree, file); >>>>>>> Why is that better? It's essentially two inline context diffs, so you can see what each side did. Much easier to merge when you can tell what is going on. The GUI tools give you the second style as well as some extra windows so you can see the checkin comments associated with both the deleted and the added lines, which gives you yet more information. > (on the other hand SCM makes it MUCH easier > to deal with the 'cleanly applied' part :) > > > Tracking of patches is much easier. > > not really : how do you make sure that all the > correct patches have been applied? All SCM > lets you gain is knowing what patches have > been applied, not what patches were NOT applied. You're assuming the common denominator of SCM systems. That's not BK. The easiest way to see if your patch is in Linus's BK tree is this: bk push -nl bk://bk.kernel.org/released That will list everything in your tree which is not in his tree. There are other ways to do it as well, but you get the idea. > > Access control is much easier. > > but if it's only Linus, then this is a moot point :) But it isn't only Linus. Again, you are assuming a CVS/Perforce/etc style SCM system. BK isn't like that. Each workspace is a repository and you can move data between them in any way that you want. That's the whole point, you can put staging areas between Linus and the unwashed masses. And if the structure you come up with turns out to be wrong, hey, no worries, just change it. BK does the right thing. > ok, i have to go learn bitkeeper now so i can answer this > intelligently, but i'll give some examples from perforce I strongly urge you to go to www.bitkeeper.com, click on Test Drive, download BK, and try it. It walks you through all the basics as well as a merge, demo-ing the GUI file merge. > Common task 1 : usability > perforce tracks what everyone has. this means that if you want > to do a sync to current, it only gives you what's changed since > your last sync, because it knows, and you didn't do anything > without telling it, right? Right. > well, what if i'm working on 2.5 stuff for my magical danaDriver? > It's really intense, has a lot of files all over the place, and I > don't want to hurt anything. Then someone asks me about the > interaction between danaDriver and reiserFS in 2.4.17 and I want > to make sure I can see exactly what they're talking about. > > so what i want to do (and i can't do in perforce, well, not easily) > is to make a clean checkout of the last 'official release' of the > whole project from SCM _without_ affecting my workspace. > > i.e. i do NOT want to create a new workspace, i do not want to create > a special directory, i just want to do : > mkdir linux > cvs checkout linux -tag 2.4.17 > and get the whole linux-2.4.17 source code, without affecting my working > directory 'linux-2.5' which also has the linux/* (main)branch checked out. Trivial in bk, do a "bk help clone". And it doesn't have to be a tagged release either, all changes (aka cvs commits) are reproducible snapshots of the tree. It's like you followed every cvs commit with a cvs tag except lots lots faster. > This is something perforce does REALLY well. > I can do this : > - set it up so anyone can submit a change request [patch] but it has > to be approved by the directory/file's owner first. if it's not > approved, it can't be submitted. bk help triggers > this means that ANYONE can submit a patch, and everyone gets to > participate, and accountability is maintained. Yup. > - set it up so that interested parties get notified of every change > that is submitted, including a web link to the full diffs of that > change. notification is file/directory based, and can have 'excludes' > so rik can get notified every time 'virtualmemory.c' is changed so > that way he can start flaming andrea right away :) :) :) :) :) bk help triggers http://linux.bkbits.net -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - 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/