FreeBSD 9.1 RC1 Finally Surfaced This Week

[nslay]

Hmm... Seems to be working with SVN without the FreeBSD template patch. So either before I handled going from CVS->SVN wrong, or the FreeBSD folks now apply their own patch to svn no matter what and made the template portion optional. By CVS->SVN, you don't mean previously having /usr/src as CVS and then doing a "svn co url:/path/to/whatever /usr/src", right? I believe svn will still complain if you try to checkout to a populated directory (I generally use git these days so I'm a little rusty). Or do you mean simply getting rid of the cvs'ed tree and going with svn? Looking at the source files, it doesn't seem like that will be an issue either... guess I'll get back to you on this after rebuilt everything with the latest source.

I think we're talking about 2 different things... when I initially did a svn checkout a few years ago (without specifying to use the FreeBSD patch) of the source years ago... the tags in the files were wrong... Instead of having numeric values, there were just questions in their place. I had to recheck everything out using the patched svn. I then found that ports still wasn't available via svn so I decided the whole thing was half-baked and went back to using cvsup. I'm using svn to checkout the source while I type this post, and so far it seems the tags have the appropriate values so it seems no freebsd patch is needed to properly check things out properly anymore (the template patch is if you're a FreeBSD dev for those who don't know).

Anyway, so having the tags in the files having question marks instead of the proper values is what caused the issues with mergemaster. Mergemaster uses those tags to determine whether the file may or may not needed to be updated. Mergemaster is the FreeBSD equivalent to Gentoo's etc-update. I'm sure you know all of this, but I'm putting it here for informational purposes.

From what I remember from years ago, If you've been using CVS, then all the files in /etc will have different version headings than SVN (e.g. something like $CVS Id ... blah blah$). The first time you use SVN, mergemaster will inquire for every single file in /etc since the version headings for SVN are different. You'll only have to tolerate this once though.

[hiryu]

With FreeBSD templates turned off, this has not been my experience. I synced just Saturday and did not experience mergemaster inquiring about every file ... just the few that I had changed.

However, when you go from CVS -> SVN, this will happen (heads up). It should only happen that one time though.

Hmm... Seems to be working with SVN without the FreeBSD template patch. So either before I handled going from CVS->SVN wrong, or the FreeBSD folks now apply their own patch to svn no matter what and made the template portion optional. By CVS->SVN, you don't mean previously having /usr/src as CVS and then doing a "svn co url:/path/to/whatever /usr/src", right? I believe svn will still complain if you try to checkout to a populated directory (I generally use git these days so I'm a little rusty). Or do you mean simply getting rid of the cvs'ed tree and going with svn? Looking at the source files, it doesn't seem like that will be an issue either... guess I'll get back to you on this after rebuilt everything with the latest source.

I think we're talking about 2 different things... when I initially did a svn checkout a few years ago (without specifying to use the FreeBSD patch) of the source years ago... the tags in the files were wrong... Instead of having numeric values, there were just questions in their place. I had to recheck everything out using the patched svn. I then found that ports still wasn't available via svn so I decided the whole thing was half-baked and went back to using cvsup. I'm using svn to checkout the source while I type this post, and so far it seems the tags have the appropriate values so it seems no freebsd patch is needed to properly check things out properly anymore (the template patch is if you're a FreeBSD dev for those who don't know).

Anyway, so having the tags in the files having question marks instead of the proper values is what caused the issues with mergemaster. Mergemaster uses those tags to determine whether the file may or may not needed to be updated. Mergemaster is the FreeBSD equivalent to Gentoo's etc-update. I'm sure you know all of this, but I'm putting it here for informational purposes.

[nslay]

Can you leave in the freebsd patches without turning off the template? Because without the FreeBSD specific support, svn won't setup the tags in the files for /etc for you, causing mergemaster master to look at EVERY file.

With FreeBSD templates turned off, this has not been my experience. I synced just Saturday and did not experience mergemaster inquiring about every file ... just the few that I had changed.

However, when you go from CVS -> SVN, this will happen (heads up). It should only happen that one time though.

[hiryu]

I think that's only true if you're going to commit to the src tree. I turned off the FreeBSD Templates (it's an option in devel/subversion) since that interferes with other SVN repositories you commit to (you get a FreeBSD template commit message instead of an empty one).

Can you leave in the freebsd patches without turning off the template? Because without the FreeBSD specific support, svn won't setup the tags in the files for /etc for you, causing mergemaster master to look at EVERY file.

I've tried portsnap in the past and didn't care for it... Maybe I was just too set in my ways. I'll give it another shot.

[nslay]

Yah, that must be why. Can you get ports over svn yet?

I think portsnap is better for ports than either CVS or SVN. It's certainly faster than CVS. Try it out!
(EDIT: To answer your question, no, not yet.)

First time use:

portsnap fetch extract

Update (much faster than CVS):

portsnap fetch update

I've held off on svn, because you have to build it with the FreeBSD specific patches. The change in functionality is minor (just extra stuff you don't have to use when the commit message), but it does annoy me. Oh well, I'm using git for almost all my personal projects now anyway, and I can man up over something that really doesn't affect me anyway.

I think that's only true if you're going to commit to the src tree. I turned off the FreeBSD Templates (it's an option in devel/subversion) since that interferes with other SVN repositories you commit to (you get a FreeBSD template commit message instead of an empty one).

[hiryu]

In my experience, if you're syncing from stable/9 (SVN or CVS), you'll never see a 9.X-BETA# or 9.X-RC# ... at least, I've never seen this. It's always been PRERELEASE for me. I think if you want 9.1-RC1, you'd need to sync from releng/9.1 (here)

I've most certainly seen this many times, but probably this hasn't been the case for quite and a while, and I finally just noticed.

[hiryu]

CVS is also being marked as "legacy" in the sense that the 10.* releases won't be tagged in CVS.

Yah, that must be why. Can you get ports over svn yet?

I've held off on svn, because you have to build it with the FreeBSD specific patches. The change in functionality is minor (just extra stuff you don't have to use when the commit message), but it does annoy me. Oh well, I'm using git for almost all my personal projects now anyway, and I can man up over something that really doesn't affect me anyway.

[archibald]

Also, I recommend using svn instead of cvsup. It's more useful for debugging since it includes the revision in the uname (you can file a PR and include the exact revision).

CVS is also being marked as "legacy" in the sense that the 10.* releases won't be tagged in CVS.

[nslay]

I have 9.1-PRERELASE and I've had it since before Thursday:
hiryu@hostname:~$ uname -a
FreeBSD hostname 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Aug 18 17:16:25 PDT 2012 root@hostname:/usr/obj/usr/src/sys/HOSTNAME amd64
hiryu@hostname:~$ uptime
9:57AM up 7 days, 15:54, 3 users, load averages: 0.02, 0.03, 0.00
hiryu@hostname:~$ date
Sun Aug 26 09:59:54 PDT 2012

I also verified I have the latest source for 9.1 today. Why is it 9.1-PRERELEASE instead of RC1? I don't know... But maybe the cvsup mirror I'm using is lagging behind? But that would be a few days behind. Maybe I'll ask on IRC.

Note: I run FreeBSD on my home server (as you see here, and since it's not so mission critical, I can upgrade it to a PRELEASE without real cause for concern) and my server at the colo (which is still 8.3, I'm waiting for 9.1 before going to the 9.x series there). Otherwise I run Kubuntu as the desktop OS on my desktop, my laptop, and the family computer.

In my experience, if you're syncing from stable/9 (SVN or CVS), you'll never see a 9.X-BETA# or 9.X-RC# ... at least, I've never seen this. It's always been PRERELEASE for me. I think if you want 9.1-RC1, you'd need to sync from releng/9.1 (here)

Also, I recommend using svn instead of cvsup. It's more useful for debugging since it includes the revision in the uname (you can file a PR and include the exact revision).

TOASTER% uname -a
FreeBSD TOASTER.LOCAL 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r239684: Sat Aug 25 14:48:42 EDT 2012 [email protected]:/usr/obj/usr/src/sys/TOASTER amd64

[hiryu]

Hmmm...

I have 9.1-PRERELASE and I've had it since before Thursday:
hiryu@hostname:~$ uname -a
FreeBSD hostname 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Aug 18 17:16:25 PDT 2012 root@hostname:/usr/obj/usr/src/sys/HOSTNAME amd64
hiryu@hostname:~$ uptime
9:57AM up 7 days, 15:54, 3 users, load averages: 0.02, 0.03, 0.00
hiryu@hostname:~$ date
Sun Aug 26 09:59:54 PDT 2012

I also verified I have the latest source for 9.1 today. Why is it 9.1-PRERELEASE instead of RC1? I don't know... But maybe the cvsup mirror I'm using is lagging behind? But that would be a few days behind. Maybe I'll ask on IRC.

Note: I run FreeBSD on my home server (as you see here, and since it's not so mission critical, I can upgrade it to a PRELEASE without real cause for concern) and my server at the colo (which is still 8.3, I'm waiting for 9.1 before going to the 9.x series there). Otherwise I run Kubuntu as the desktop OS on my desktop, my laptop, and the family computer.