From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2563 invoked from network); 9 Sep 1999 19:01:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Sep 1999 19:01:53 -0000 Received: (qmail 10531 invoked by alias); 9 Sep 1999 19:01:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7762 Received: (qmail 10524 invoked from network); 9 Sep 1999 19:01:22 -0000 Date: Thu, 9 Sep 1999 12:01:20 -0700 (PDT) From: Wayne Davison To: Zsh hackers list Subject: Re: BK & CVS (slightly off-topic) In-Reply-To: <19990909094409.A29631@caerdonn.eurocontrol.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 9 Sep 1999, Ollivier Robert wrote: > But it uses SCCS (albeit modified). I'm not sure but I don't think > there is the equivalent of anoncvs. In my understanding of how BK works, this is not required. I'm fuzzy on some details (not having used it yet), but the web page makes it clear that everyone has their own copy of the archive and works locally on that, so there is no need for direct remote archive access. Combine this with an extended "patch" format (called a changeset) and the ability to merge archives together, and everyone's local archive can be synchronized to reflect the same (essential) version control information. Note also that each user has control over how much "detail" gets put into a patch, so it should be possible for someone to check a whole bunch of incremental changes into their local archive and then just release the patch as one incremental change (if desired). (Yes, I believe that this means that the SCCS version numbers on various machines are not identical, but BK appears to use names to work around this.) What I think this means in practice is that you start things going by distributing a tarred/gzipped archive snapshot (a collection of SCCS files that was perhaps created via some kind of export command) and making it available for download. Someone could keep up to date by periodically re-downloading a new archive and merging it into their local version, but the better way to go would be to apply one or more patch files (which _does_ update all the appropriate version- control info such as change-log comments, symbols, etc). It is my understanding that PK makes it easy to apply as many or as few incremental patches from the development contributors as you like, and it will sort out the whole mess when you apply an incremental collection of changes (in our case, a new pws patch) that may already contain the changes you've applied. So, if I understand things correctly, this means that there is not instant access to every little twiddle that someone might make to an anonCVS archive, but instead you have to use "commit" and "makepatch" to share your changes. I think this will be a good thing, since you can't accidentally check out a partial commit. However, I'll reserve final judgement until I can actually use it to see for sure. ..wayne..