Date: Sat, 13 Nov 2010 03:01:57 -0500 From: grarpamp <grarpamp@gmail.com> To: freebsd-hubs@freebsd.org Subject: CVSup/csup vs. rsync [also git] Message-ID: <AANLkTi==Nc5p1XjUxE=4ndj1r0UzAm5gzW2Ue8f7Jr=H@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi==Nc5p1XjUxE=4ndj1r0UzAm5gzW2Ue8f7Jr=H>