Domain: cvsup.org
Stories and comments across the archive that link to cvsup.org.
Comments · 7
-
Been there with CVSup
We welcome our Git brothers for reinventing the wheel again versus CVS's established http://www.cvsup.org/ for mirroring and distribution.
The more the merrier.
-
Re:OpenCVS?
CVS stays very much relevant to whole BSD community (not only OpenBSD).
It's because of the tradition, sure - and rather faint convicting force of some other version control system ...
Just look at the way CVSup http://www.cvsup.org/ is used.
These people just need a CVS software they would like to maintain for some time in the future. -
Re: csup
With 6.2, csup is even better...
To elaborate
CVSup is *the* way to update the software and the OS on FreeBSD. You keep your /usr/ports tree and src distribution of the OS in sync with the official repositories using it. It is very similar to rsync, but takes advantage of CVS source code repositories (FreeBSD is stored in CVS).
It is a great tool, and really the only downside to using it is that it was written in Modula-3. Building CVSup from sources required a *lot* of time and was unnecessarily complex. To remedy this, the author of CVSup released a language called ezm3, which is basically a stripped down version of the Modula-3 source base that "contains only those components which are required for building and running CVSup". So to build CVSup, you first built ezm3.
As you can imagine, getting Modula-3 compiled on your system (even if it is a stripped down version of Modula-3), just to run CVSup was seen as overkill. But what really prompted work on csup (according to the authors) was because "the Modula-3 runtime environment was not ported to all the architectures supported by the various *BSD projects, and it was becoming increasingly harder to find people for maintaining the code."
csup is a rewrite of the CVSup software in C. I It is pretty fast, but currently supports checkout mode only -- not that big a deal, since most people only us CVSup to keep their ports and OS src trees in sync with the upstream repositories. Furthermore, since it is written in C, this has allowed them to put it in the base FreeBSD distribution instead of shipping it as a separate package. -
Re:backups
Why aren't you getting more than 23MB/sec? Running out of CPU with your scp?
Have you tried a nonencrypted network copy of similar sized dummy data? How fast is it?
If the data doesn't change that much every night and you have enough disk space on the tape server you could try using cvsup. But you need enough CPU to keep up. -
Re:cvs
Why not just use CVS or, even better, subversion?
You should use CVSup for this.
It has already proven its useability for syncing and updating FreeBSD systems -
the OpenBSD team answers another FAQ unix questionvia the OpenBSD FAQ:
8.6 - Should I use Ports or Packages?
In general, you are HIGHLY advised to use packages over building an application from ports. The OpenBSD ports team considers packages to be the goal of their porting work, not the ports themselves.Building a complex application from source is not trivial. Not only must the application be compiled, but the tools used to build it must be built. Unfortunately, OpenBSD, the tools, and the application are all evolving, and often, getting all the pieces working together is a challenge. Once everything works, a revision in any of the pieces the next day could render it broken. Every six months, as a new release of OpenBSD is made, an effort is made to test the building of every port on every platform, but during the development cycle it is likely that some ports will break.
In addition to having all the pieces work together, there is just the matter of time and resources required to compile some applications from source. A common example is CVSup, a tool commonly used to track the OpenBSD source tree. To install CVSup on a moderately fast system with a good Internet connection may take only about ten seconds -- the time required to download and unpack a single 511kB package file. In contrast, building CVSup on the same machine from source is a huge task, requiring many tools and bootstrapping a compiler, takes almost half an hour on the same machine. Other applications, such as Mozilla or KDE may take hours and huge amounts of disk space and RAM/swap to build. Why go through this much time and effort, when the programs are already compiled and sitting on your CD-ROM or FTP mirror, waiting to be used?
Of course, there are a few good reasons to use ports over packages in some cases:
- Distribution rules prohibit OpenBSD from distributing a package.
- You wish to modify or debug the application or study its source code.
- You need a FLAVOR of a port that is not built by the OpenBSD ports team.
- You wish to alter the directory layout (i.e., modifying PREFIX or SYSCONFDIR)
-
or use rdiff-backup or cvsupOr use rdiff-backup or cvsup.
rdiff-backup is:
rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup. rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership, and modification times. Also, rdiff-backup can operate in a bandwidth efficient manner over a pipe, like rsync. Thus you can use rdiff-backup and ssh to securely back a hard drive up to a remote location, and only the differences will be transmitted. Finally, rdiff-backup is easy to use and settings have sensical defaults.cvsup is:
CVSup is a software package for distributing and updating collections of files across a network. It can efficiently and accurately mirror all types of files, including sources, binaries, hard links, symbolic links, and even device nodes. CVSup's streaming communication protocol and multithreaded architecture make it most likely the fastest mirroring tool in existence today.