going from cvs to svnq
keramida at ceid.upatras.gr
Wed Apr 1 19:54:58 PDT 2009
On Tue, 31 Mar 2009 22:18:33 -0400, Chuck Robey <chuckr at telenix.org> wrote:
> What I don't know is, I use cvsup all the time, but when I switch to
> svn, what does the "cvsup" job of tracking an archive (not tracking
> the sources, I mean the archive)? Does svn do it all itself? If so,
> I can find out how, I just want to know if that's how its done. If
> not, what's the general tool used to track the freebsd archive, so I
> can investigate it?
CVSup does two things:
* It can check out copies of all the files in a remote repository,
using date- and time-based snapshot info, or just CVS tag names.
* It can mirror the RCS metadata of a CVS repository.
These two operations are replaced, in a Subversion world, by the svn(1)
client and a utility called svnsync(1).
The svn(1) client can check out a snapshot of the Subversion repository
using a revision ID, a date, or one of the special tag paths we have in
the Subversion repository. The syntax for specifying the revision is
slightly different from CVS, but more on that later.
The good thing about svn(1) is that its operation is actually 'safer'
than cvs(1) or CVSup, because a revision is either fully committed into
the remote repository or is isn't. You can't check out half of a change
from a Subversion repository, because you were unlucky enough to run the
client when only half of a commit had been stored into the repository.
I expect this sort of 'transactional' property of the Subversion tree to
appeal a bit to all the users. Those who run CURRENT will like the fact
that they won't get half of a commit, spend a few hours chasing down
build problems, and then realize they could have avoided all that by
checking out a full copy. Even the users who run STABLE will probably
be a bit happy about this sort of transactional behavior of commits,
because it means that in periods of high checkout load (i.e. right after
an important security fix), they know that they either _have_ the change
that fixes the issue or that they _don't_ have it.
Checking out sources:
Checking out with svn(1) is currently supported by the online
Subversion repository, which is read-only to everyone and is
You can point an svn(1) client there and check out parts of the source
repository. Please do *not* check out a full copy of the _entire_
tree though. It will contain dozens of branches and several dozens of
vendor applications that you most certainly _don't_ care about, and it
will put a huge load on the Subversion server for no useful purpose.
Before checking out with svn(1) you should take a bit of time to
browse the repository and see its structure and there each branch
lives. There is a web interface for the repository at:
This should be a bit friendlier looking than the raw 'svn over http'
pages of the `http://svn.freebsd.org/base/' URI.
The branches that are most interesting for checking out source
URI CVS-style name
If you want to check out a copy of `7-STABLE', you can use the
% svn co http://svn.freebsd.org/base/stable/7 stable-7
This should create a local directory called `stable-7' with the full
source tree of the CVS branch called `RELENG_7'.
If you want to check out the security branch `RELENG_7_1', because you
want to get the security bug-fixes of the 7.1 release, you can use:
% svn co http://svn.freebsd.org/base/releng/7.1
Finally, if you want to check out the sources at the time the release
of FreeBSD 7.0-RELEASE was cut, you can use:
% svn co http://svn.freebsd.org/base/release/7.0.0
Subversion is a bit wasteful with disk space. A full checkout of the
`/head' branch takes more than *double* the space of a CVS checkout.
This may, essentially, mean that on systems with limited disk space it
may be sensible to stick with CVS checkouts (or NFS mount the `src'
directory) for now.
`svn update' is a bit faster than `cvs update'. For checkout trees
that have no or very little local changes, it is almost blazingly
faster than `cvs update'.
Keeping a local repository mirror:
There is a tool called `svnsync' that can mirror the entire SVN
repository to a local svn repository copy. I am not aware of any tool
that can synchronize only *parts* of the repository history though.
Its setup is a bit more convoluted than CVSup, and synchronizing into a
completely `empty' local mirror will take ages. I will have to talk a
bit with the repository admins for the best plan of making it easier to
use `svnsync' or the plans for svnsync mirrors (like the CVSup mirror
More information about the freebsd-questions