Can't resolve HEAD releases to real versions

If you had a release node pointing to HEAD, this wouldn't be a problem.
Feel free to use the settings to have update_status ignore this module if you prefer.

Actually, it's not that I "won't fix" this. Really, it's not a problem at all -- you can already solve this yourself in 1 of 2 ways.

I'm assuming:

a) you have the latest cvs_deploy and update_status installed and working
b) your local copy of sitedoc is a regular CVS checkout from cvs.d.o
c) you "Check manually"'ed recently and have accurate available update data

if all that's true, i don't see how update_status could be telling you your locally installed version is just "HEAD". please either provide screenshots and more info, or confirm that the problem went away when you refreshed and/or updated everything.

in terms of your question -- no it's not the sticky tags that matter (those just affect your local workspace), it's creating branches (an operation in the repository itself). yes, you should make DRUPAL-5 branches before you start porting to D6 in HEAD. see http://drupal.org/node/17570

I don't understand "it is the original source with CVS on top of it." What does that mean?

Can you post a directory listing and the contents of every file in the "CVS" folder in one of these directories, for example: c:\www\drupal\sites\all\modules\sitedoc\CVS

I'm assuming there's no "Tag" file in there, but there *is* a "Repository" file and a "Root" file. I'm curious what those files contain, and if those files in fact exist. I must admit, I've never tried to use CVS on a windoze machine, so it's entirely possible cvs_deploy is confused since it was written by and for *nix users. ;)

Also, please include the contents of sitedoc.info.

Thanks for the info. The data you provided made me say to myself "in-con-CEIV-able". ;) So, I tried it locally, and lo, it's broken. Tee hee, whoops. ;)

Please try the attached patch to cvs_deploy DRUPAL-5. Works for me. Please confirm it's working for you, too. Thanks. Note, because of the differences between D5 and D6, this bug isn't present in the D6 version of cvs_deploy.

Also, note: there's a slightly weird edge case where if you view admin/build/modules or admin/logs/updates when you have no available update data, cvs_deploy can't resolve 'HEAD' into something better. So, you should reload either page as soon as you visit the admin/logs/updates page or "Check manually". Nothing much I can really do about that, unfortunately.

That's a separate problem. cvs_deploy is trying to specify the 'datestamp' attribute for -dev releases based on the modification times on the CVS/Entries files. http://drupal.org/node/158526 u_s then has to compare these against the datestamps of the tarballs on d.o in the XML release history files. it's entirely possible that due to timezone or other clock skew, if your checkouts are from pretty close to the same time, that cvs_deploy thinks the d.o versions are newer. I don't really care, either: u_s is not meant to be perfect when people use -dev and branches. In fact, it's sort of against Earl and my better judgement that it supports them at all -- we'd rather maintainers created and users used, official releases from tags. 1 possible work around that should even work on windoze: remove a file from your workspace (e.g. the README.txt) and checkout again, and CVS/Entries will be newer than the latest tarball on d.o and u_s will be happy.

Given that my patch fixes the actual bug here, I committed to DRUPAL-5.

Yes, of course. You should batch small changes into official releases. My point is, why should I spend any time worrying about what update_status tells you about your own -dev code?