[ On Friday, February 11, 2005 at 11:25:55 (-0600), Eric Haszlakiewicz wrote: ]
> Subject: Re: mono experience cutting to subversion
>
> 	supposedly rsync works ok with fsfs backed repositories.  However, since
> the existing fsfs files will (almost) never change and new changes just add
> new files, rsync is needlessly inefficient.  There are probably better ways
> to sync a svn repository.

That's the same kind of problem that effectively started this thread.

And the problem is not with the version control system per se, but
rather with abusing rsync as a mass distribution mechanism.

Rsync is needlessly inefficient with CVS too, especially with dozens or
hundreds or thousands of clients all usually getting the same updates.

The various smart logging schemes, from FreeBSD's CTM on up, could work
as well with CVS (or presumably with any other change control system),
but they all (except CTM) require some new coding (and CTM probably
isn't really all that efficient for whole repositories anyway).

The old "track" system written at bellcore by Daniel Nachbar and then
fixed and improved and otherwise hacked upon at the UofT is, IIRC, a bit
closer to what we're really looking for since it keeps track of changed
files on the server and allows the clients only to request those files
changed since their last update.  However I think it is still far from
ideal for this particular purpose.

I think CVSup really is the best way to serve a CVS repository since it
understands not only the directory structure a repository lives in, but
also the internal format of the RCS files in the repository, and it uses
a very efficient protocol (in terms of multi-threaded communications and
I/O interleaving & overlaying, all without using ACKs or cycles in the
protocol states).  At the OS level the caching of the directory
hierarchy, along with the changes  It realy is stunning how fast CVSup
runs and how comparatively little overhead it uses.

But we really do need ability to compile CVSup natively on at least the
"major" NetBSD CPUs, and with the advent of ezm3 that problem should
finally be solved (it uses the GCC-3.2.3 code generator), and it is
already claimed to work on NetBSD/i386 as well as FreeBSD/alpha,
FreeBSD/sparc64 and SunOS/sparc so except for minor tweaks that should
cover all the (important) bases.

FYI, CVSup also has one other really incredibly important and
fantastically cool feature that makes its use HIGHLY desirable for any
and all third-party code users such as myself:

   CVSup is able to merge new deltas and tags from the server with
   deltas and tags added locally on the client machine.  This makes it
   possible for the client to check local modifications into his
   repository without their being obliterated by subsequent updates from
   the server.

This means folks such as myself can use our local copy of the CVS
repository directly to track our own local changes and even create our
own local branches without having to use the horribly inefficient and
tricky "cvs import" tricks.

CVSup also provides similarly highly efficient ways for people to track
a given branch just as they might do with an anoncvs checkout, but
without all the overhead of running a full, shared, anon. CVS server.


The only other reasonably mature version tracking system I know of that
would seem to be directly suitable to meeting the needs of NetBSD, and
at the same time provide this ultra-cool local modification support ala
CVSup, is BitKeeper.

Monotone should be able to do this too, IIUC, and Monotone will
eliminate the redistribution issues since it inherently propogates
changesets and is pretty much network protocol agnostic, but of course
Monotone is still under development.

DARCS is another one that's entirely changeset based, but I know even
less about how well it might work for a project like NetBSD.

I don't think Subversion comes even close to meeting any of these needs.


In any case CVSup should help solve the resource starvation problems
with distributing NetBSD sources, and as a solution it only fixes the
broken part -- it doesn't require a whole new world order to be
established first.

It's long past time I got back to work at getting CVSup on NetBSD!  :-)

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>