[ On Wednesday, April 28, 1999 at 22:41:11 (-0300), David Maxwell wrote: ]
> Subject: Re: CVSup collections for a NetBSD CVS tree
>
> Not the point. I'd have to agree with other people's comments that
> NetBSD should not encourage use of something which is largely non-ported.

I think making CVSup just *one* of the means of accessing NetBSD CVS
repository is at worst merely a way of encouraging the porting of
something useful so that it is more widely accessible!

I also think that NetBSD users and developers should promote their CVS
repository in all possible ways, not spread F.U.D. about the tools that
it might use to do this.  Can I scream "A bad case of N.I.H. syndrome
strikes again!!!!"  yet?

> If we need a good (and portable) tool, we should consider creating one 
> that matches other goals of NetBSD.

I personally wouldn't even dream of trying to re-invent or even
re-implement CVSup, not even if I had all the spare time it would take
to do so.  It does what it does very well and it's already freely
available and well maintained.  I'd much rather invent a better CVS! ;-)

To be rhetorical I might ask just what unique goals might NetBSD have
w.r.t. it's hopefully soon to be publicly available CVS repository that
might differ from any similar projects goals anyway?  How could they
possibly be at odds with a tool who's job it is to distribute CVS
repositories in the most effective and efficient method possible? ;-)

> What are the main gains of CVSup? Multi-threaded, sends diffs only,
> anything else? People have only commented that it's faster.

I was extremely impressed with CVSup when I was using it semi-weekly to
mirror the FreeBSD repository.  At that time, about a year ago, I was
working for a client who was on the end of a 512Kbps PSI-NET link in
Toronto and connecting to cvsup.freebsd.org (I don't know if that's
still pointing the same place, or not).  I was running it on a hefty
300MHz PII with a pair of mirrored UltraF+W Cheetas, under FreeBSD of
course, and everything I did with it was extremely speedy compared to
plain old SUP.

As I understand it CVSup does much smarter things than just send diffs.
It sends just the changes to the structure of the RCS files (eg. new
deltas, new tags, new comments, etc.), as well as adding new files, and
possibly deleting old ones (though deleting should never really happen
in a CVS repository).  It seems to understand RCS files and the CVS
repository intimately.

It's *BLINDINGLY* fast compared to rsync, at least from the client
perspective.  For example I've an 8KB source file with ~160 deltas of
1-2 line changes, each with a 1-line comment, and this file is already
48KB.  Rsync would have no choice but to send all 48KB, yet CVSup need
only send the few tens of bytes each delta and comment consists of
(assuming it is run on average once after each delta is committed).
With real source and documentation files it's not uncommon for often
changed ,v files to be at least an order of magnitude larger than their
total size, yet the deltas will only be a few percent of their size, and
perhaps only one or two percent, or less, of the ,v file's size.  A
gross measure of the ratio between the actual NetBSD repo and a working
directory would provide an even more life-like guesstimate as to how
much more efficient CVSup could be over rsync or sup of the repo and a
working dir, even if one line in every file were changed in one
iteration.

I've not yet run the CVSup server in an environment with many
simultaneous clients, though I don't doubt the word of the FreeBSD folks
on their experiences.  No doubt it requires more CPU on the server side
than rsync, but as I recall it has settable connection limits, etc.
Rsync on large directory trees isn't exactly light-weight either.  I've
never run a plain old SUP server, so I've no idea how it compares,
though sup'ing NetBSD never seems to be all that speedy if there are any
significant number of changed files.  Sup'ing ,v files would obviously
be much slower and take much more bandwidth.

Note that this allows you to have a unique local tag in the local copy
of the repository -- eg. to mark when you last did a "cvs export" so
that you could import it into your own private repository, or just to
mark when you last did a "make build", etc.  It might even be possible
to create local branches in the copy, though care must be taken to
ensure branch numbers can never clash (i.e. pick really big starting
numbers that are unlikley to ever be used in the official repo), and of
course there's no really easy "canned" way of doing this with CVS (yet).

Besides, it's a really cool system, and with the X11 client it is lots
of fun to watch in action too!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>