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)
By Oliver Klima (oklima) mail@oliverklima.de on http://openbsd.oliverklima.de
That's what I use to update the sources from varying repositories and requires no magic at all.
Comments
By Sean Cody (sean) on I don't work here.
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.
By phessler (phessler) on http://theapt.org
Yes, but then you have to run with -d every time you update. The OP's method only requires it to be ran once.
Comments
By Oliver Klima (oklima) on
Well, that's the point I overlooked and definitely a reason to use some magic.
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
You will see a section that looks like this:
Just change the
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.Comments
By phessler (phessler) on http://theapt.org
>
> 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.
Comments
By Ted Walther (TedWalther) on http://reactor-core.org/
> >
> > 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?
Comments
By phessler (phessler) on http://theapt.org
>
> 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.
By Nicholas Marriott (nicm1) nicholas.marriott@gmail.com on