QUOTE (X-Istence)
I read his text as saying the server contained theports tree at the timeit was frozen for RELENG_5_2
It does. Sorta. It is possible to get back to any release level that is still in the cvs tree (anything => FreeBSD 2.0; the 1.x tree isn't in the live cvs for encumbrance reasons)
Because of the way cvs works (and the way the FreeBSD group uses it), releases are marked with symbolic tags, so you could checkout (cvsup) the ports tree for RELEASE_2_2_1, RELEASE_4_0_0, or RELEASE_4_10_0 if you wanted to.
A note about how FreeBSD does cvs tree tagging:
The Ports tree is tagged with RELEASE_#_#_# for each release. This is the state of the ports tree at the time of the release.
The source tree is branched at various places, those get RELENG tags (Release Engineering), so there's a RELENG_2, a RELENG_3, a RELENG_4 and now a RELENG_5. These branches are referred to as stable branches. There are then more tags for each release, so there is a RELENG_5_2_RELEASE for FreeBSD 5.2.0. After a release there is another branch for what's referred to as a security or maintenance branch, so there's a RELENG_5_2 that got all of the show stopper fixes after 5.2.0. This branch eventually became FreeBSD 5.2.1 with it's matching RELENG_5_2_1_RELEASE tag.
The early releases for a major version (3, 4, 5, etc) are a special case. The branch for RELENG_5 didn't appear until the last couple of weeks when FreeBSD 5.x was judged to be "stable"[1]. There is a similar window for the 4.x tree (IIRC). FreeBSD 5.0 and 5.1 were built out of what cvs calls HEAD, or the top of the tree. HEAD is where the ports tree is always tagged and checked out from.
There's quite a bit more information about how FreeBSD does Release Engineering here:
http://www.FreeBSD.org/releng/index.html.
[1] Stable doesn't mean that it doesn't have major bugs (RELENG_5 does have several show stoppers left in it). It does mean that large architectural changes aren't supposed to take place and people are not supposed to break it in unfortunate ways. In other words, the major interfaces are not supposed to change and no one is supposed to break the clean building of the source tree into the final OS product. It also has some other internal policy ramifications related to testing, code reviews and commit approvals.