zsh-workers
 help / color / mirror / code / Atom feed
From: Wayne Davison <wayne@clari.net>
To: Zsh hackers list <zsh-workers@sunsite.auc.dk>
Subject: Re: BK & CVS (slightly off-topic)
Date: Thu, 9 Sep 1999 12:01:20 -0700 (PDT)	[thread overview]
Message-ID: <Pine.GSO.4.10.9909091119070.9510-100000@house.clari.net> (raw)
In-Reply-To: <19990909094409.A29631@caerdonn.eurocontrol.fr>

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..


  reply	other threads:[~1999-09-09 19:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-06 10:19 3.1.6-pws-3 Peter Stephenson
1999-09-06 11:18 ` 3.1.6-pws-3 Andrej Borsenkow
1999-09-07 16:29 ` 3.1.6-pws-3 Bart Schaefer
1999-09-08  9:00   ` CVS Peter Stephenson
1999-09-08 10:40     ` CVS (slightly off-topic) Adam Spiers
1999-09-08 13:44       ` Ollivier Robert
1999-09-08 17:26         ` Bart Schaefer
1999-09-08 20:03           ` BK & " Wayne Davison
1999-09-08 22:30             ` Bart Schaefer
1999-09-09  0:01               ` Wayne Davison
1999-09-09  7:44             ` Ollivier Robert
1999-09-09 19:01               ` Wayne Davison [this message]
1999-09-16 15:46       ` Adam Spiers
1999-09-18  7:04         ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.GSO.4.10.9909091119070.9510-100000@house.clari.net \
    --to=wayne@clari.net \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).