Thank you all. :)

By the end of this thread, I know a lot more abt pkgsrc and updating
through CVS. Cool! Just sumarizing for future reference:

1) The path where pkgsrc is stored does not matter. I can have it
anywhere I want. pkgsrc uses relative paths internally.

2) All the CVS directories that I see littered around in pkgsrc are
actually CVS meta information. Used by CVS to update my pkgsrc tree to
the current one.

3) The tarball has all these CVS directories. So you can always start
with the tarball and then keep updating using CVS.

4) And finally ... there are multiple pkgsrc trees -- the main/
current one (pkgsrc) in which all the development activities happen,
and the quarterly ones ("pkgsrc-2005Q4" and so on) that do not get
updated later except for security updates and stuff. I knew this, but
what I didnt know was that its possible to follow multiple trees on
the same machine. As in, I can have /usr/pkgsrc (for current) and
/usr/pkgsrc-2006Q1 (for 2006's Q1 tree), and I can have both of these
updates using cvs (for the latter, I have to specify the release name
with the -r2006Q1 argument).

for pkgsrc-current:
(/usr/pkgsrc/current)# cvs up -dp

for a specific version:

(/usr/pkgsrc-2005Q3)# cvs up -dp -rpkgsrc-2005Q3

Three cheers to the pkgsrc team from my side too. Really, this is an
awesome piece of work! The first time I used pkgsrc, and I saw how it
downloaded the sources and patched them and was actually building them
for my machine -- that was a "wow!" moment. One is so used to
downloading binary packages blindly usually, I had never given any
thought to compiling stuff from source. Gave me a whole new
perspective to this "open source" and "freedom" and similar concepts.
If you have the sources, then its always possible to compile it for
other platforms too -- given some first time effort. That's something
which struck me practically once I started using pkgsrc. Great work!
:)

Thanks,
Rakhesh