going from cvs to svnq

[Giorgos Keramidas]

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?

Hi Chunk,

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
  accessible at:

    http://svn.freebsd.org/base/

  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:

    http://svn.freebsd.org/viewvc/base/

  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
  snapshots are:

    URI                                           CVS-style name
    -------------------------------------------------------------------

    http://svn.freebsd.org/base/head/             CURRENT

    http://svn.freebsd.org/base/release/X.Y.Z     RELENG_X_Y_Z_RELEASE

    http://svn.freebsd.org/base/releng/X.Y        RELENG_X_Y

    http://svn.freebsd.org/base/stable/X          RELENG_X

Examples:

  If you want to check out a copy of `7-STABLE', you can use the
  command:

      % 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

Notes:

  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
servers).