OpenBSD Journal

Switching CVS repositories.

Contributed by sean on from the forrest-for-the-trees dept.

I happen to track current on my 'messing around' environment. Every so often a CVS mirror would go offline or crash or do something odd in so far as to stop me from updating my tree. In the past I would just blow away the tree on my system and do a check out from a different mirror. This of course takes far too long and is a huge waste of bandwidth and time. I figured there must be a better way.

It appears the mirror I was using (rt.fm) is now offline and of course that's where I did my last checkout. Being far away from home and on a worse than dial-up connection I had no interest in checking out a new tree so I thought a bit deeper. It turns out changing the repository isn't all that difficult.

You may have noticed in your checked out tree the CVS folder. This folder is used to store settings and details about the where/when/how of your checked out state.

Let's take a little romp through one of these folders.

# ls -l /usr/src/CVS
total 16
-rw-r--r--  1 root  wheel  277 Aug  4 10:27 Entries
-rw-r--r--  1 root  wheel   31 Aug  4 10:30 Entries.Log
-rw-r--r--  1 root  wheel    4 Sep 29  2008 Repository
-rw-r--r--  1 root  wheel   36 Aug  4 10:15 Root

That doesn't seem too bad. And Repository and Root look promising so let's take a look at those!

# cat Repository                                                              
src         
# cat Root                                                                    
anoncvs@anoncvs.ca.openbsd.org:/cvs

Bingo! Plain text config FTW! So if I change the CVS/Root file in /usr/src that will do the trick right...? Wrong, there are CVS folders throughout the tree. Now that sounds like a real pain in the ass to fix but it appears that the format of the CVS/Root file is the same throughout the tree! Now we're in business. All we need to do is create a new Root file and replace all the old ones with it (using our old friend find(1)).

echo anoncvs@[USE_YOUR_NEW_MIRROR_FQDN]:/cvs > /tmp/Root
find /usr/src -name Root -type f -exec cp /tmp/Root {} \;
rm /tmp/Root

Please choose an appropriate mirror (I purposely didn't fill one in to discourage cut-and-paste abuse) and depending on how fast your disk is it could take a few minutes . Once done you should be able to do a normal update and you'll be back on track!

There is very little 'magic' involved and with a little courage and poking around you'll find that aside from kernel panics, things are pretty easy to mess with.

What 'not exactly obvious' tricks have you come up with? Share them below or write your own story and submit it!

(Comments are closed)


  1. By Oliver Klima (oklima) mail@oliverklima.de on http://openbsd.oliverklima.de

    I fail to see why you didn't use the '-d' option of cvs(1):
    # cvs -d${CVSROOT} update -Pd

    That's what I use to update the sources from varying repositories and requires no magic at all.

    1. By Sean Cody (sean) on I don't work here.

      > I fail to see why you didn't use the '-d' option of cvs(1):# cvs -d${CVSROOT} update -PdThat's what I use to update the sources from varying repositories and requires no magic at all.

      That does work as well. The last time I tried it the result was less than I expected.

      As well the point here is to encourage people to poke around a bit and try to figure out what tools do. There are probably a few more solituons to this as well and I'm hoping people show them so that I can learn something new as well.

    2. By phessler (phessler) on http://theapt.org

      > I fail to see why you didn't use the '-d' option of cvs(1):# cvs -d${CVSROOT} update -PdThat's what I use to update the sources from varying repositories and requires no magic at all.

      Yes, but then you have to run with -d every time you update. The OP's method only requires it to be ran once.

      1. By Oliver Klima (oklima) on

        > Yes, but then you have to run with -d every time you update. The OP's method only requires it to be ran once.
        Well, that's the point I overlooked and definitely a reason to use some magic.

  2. By Ted Walther (TedWalther) ted@reactor-core.org on http://reactor-core.org/

    With git, there is only one dot-git directory to worry about. To change the location of the source repository, you edit

    .git/config

    You will see a section that looks like this:

    [remote "origin"]
    	fetch = +refs/heads/*:refs/remotes/origin/*
    	url = johnny.com:newlisp
    

    Just change the

    url = ...
    line to your new source for updates. The syntax of the url can be any syntax that is used by git clone, such as a line suitable for scp or for wget.

    1. By phessler (phessler) on http://theapt.org

      > With git, there is only one dot-git directory to worry about. To change the location of the source repository, you edit .git/config
      >
      > You will see a section that looks like this:
      >
      >
      > [remote "origin"]
      > fetch = +refs/heads/*:refs/remotes/origin/*
      > url = johnny.com:newlisp
      >
      >
      >
      > Just change the url = ... line to your new source for updates. The syntax of the url can be any syntax that is used by git clone, such as a line suitable for scp or for wget.


      Did you miss the point where the story was about _CVS_ and not about git? Of course other tools have other methods.

      1. By Ted Walther (TedWalther) on http://reactor-core.org/

        > > With git, there is only one dot-git directory to worry about. To change the location of the source repository, you edit .git/config
        > >
        > > You will see a section that looks like this:
        > >
        > >
        > > [remote "origin"]
        > > fetch = +refs/heads/*:refs/remotes/origin/*
        > > url = johnny.com:newlisp
        > >
        > >
        > >
        > > Just change the url = ... line to your new source for updates. The syntax of the url can be any syntax that is used by git clone, such as a line suitable for scp or for wget.
        >
        >
        > Did you miss the point where the story was about _CVS_ and not about git? Of course other tools have other methods.

        I know OpenBSD has been working very hard on OpenCVS. But the distributed version control wars are essentially over; git is the new standard. All the others (darcs, monotone, arc, subservsion, cvs) are slipping down the drain. Why delay the inevitable?

        1. By phessler (phessler) on http://theapt.org

          > > Did you miss the point where the story was about _CVS_ and not about git? Of course other tools have other methods.
          >
          > I know OpenBSD has been working very hard on OpenCVS. But the distributed version control wars are essentially over; git is the new standard. All the others (darcs, monotone, arc, subservsion, cvs) are slipping down the drain. Why delay the inevitable?

          what inevitable? we *like* cvs. sure, there are problems, but they are implementation problems, not protocol problems.

          this has been all discussed before. its nice that others are using different systems, but we're not interested in migrating.

  3. By Nicholas Marriott (nicm1) nicholas.marriott@gmail.com on

    The cvsutils package has (among other things) a cvschroot utility which is handy for this.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]