CVSup/csup vs. rsync [also git]

grarpamp grarpamp at
Sat Nov 13 08:25:54 UTC 2010

re: Sorry state of the rsync based CVS,replication
The benefit is organisational to us. We did use cvsup in the past but it
has been a pain to maintain as all the other external sources we keep in
sync with use rsync. That combined with the requirement for m3 etc. for
the sole purpose of syncing the CVS tree when there are alternatives
(rsync for the freebsd cvs tree and more recently svnsync) made the
switch to rsync a no brainer (note that this decision was taken long
before csup came to life).
[snip more commonality]

I can second this. No other major project that I know of is seriously using
cvsup... on the contrary, it's being abandoned. The FreeBSD cvsup mirrors
are commonly missing distributions. And I can't see any real win
over rsync -Haxi [-cz] --delete. While glad to see the dep on m3
go with csup, I still wondered aloud when it came out instead of rsync.

I guess my thought is that if you're going to be using supfiles to do
arbitrary tag/date checkouts, use the actual repo tool to talk directly
to the repo. If you're just going to be saying give me release_x, releng_x,
or head till the day I die... supply those via a looped check out on the
mirror master and rsync those. Which when doing more than one
tag wastes resources on both sides and between... so ultimately...

These days, CPU, disk, and even net are cheap and the repo is small
compared to that. I can't see any reason why people would *not*
just mirror the entire repo and then checkout whatever revision they want
from that. And there are long term efficiences with that too... mostly
in build scripts and not having to update multiple trees over the wire.

I've done perf testing that didn't make me fear rsync in full repo copy
mode, be it in CPU, or disk, or net. The only real trick is making sure
the master is setup to offer a commit atomic consistent view to the
rsync daemon. It's just an intermediate copy, zfs snapshot, etc.

And then of course there is git :) Would love to see those crypto
hashes from repo to release, gitweb, etc. But I guess for some reason
SVN won out for the time being back then. That's ok for now suppose.

On the plus from the do away with legacy side...
As SVN is the primary source for years now, I would support dropping
CVS altogether just as soon as SVN replication is adequate and
not worry about doubly supporting CVS anymore. CTM, etc.
Having SVN via svn, svnsync, and rsync would be nice, perhaps
even optionally over ssh.

> The FTP site desperately needs to go on a diet

Is that due to CPU, disk or net? Are stats available?

> Don't take this as flamebait

Ditto. Cheers :) I do hope to be able to provide an update of internal
git+rsync (and even old CVS/SVN) tests that might inspire.

More information about the freebsd-hubs mailing list