A comment to Dereks comment #1. I fully understand the concern.
I think the proposed change which gives a U at updates is the best wasy to go. The other behaviour I could propose is that the "cvs update -kk" makes a "u" for files which only are updated due to keyword expansion, and "U" for files which are updated due to any other "normal" update change. I look forward to the patch.

Okay, I have a patch for this I will probably commit shortly, when `make check' completes. It has the side effect of looking like it updates everything when any stickies change that may change file contents (options & tags), but then that was the case with updates which changed only the option stickies before.

i.e., where `cvs update -kk' would always:

U file1
U file2
...

regardless of file contents, the same now happens with updates that change the sticky tag.

I'm not sure I like this behavior. I would hazard that most users would prefer to see a `U' status only when file contents change (not just stickies in the Entries file), but this is a deeper bug to fix and should probably be opened as a second bug/enhancement.

Then I see that the label "TAG2" is inserted after the magic keyword "Name" in both files.

If I now continue running
$ cvs update -r TAG1
Then I see that "a.txt" is updated with version and TAG1 info - however "b.txt" still reads this line only
$Name: TAG2 $
since TAG1 and TAG2 for the b.txt is the same version.

However if I do
$ rm a.txt b.txt
$ cvs update -r TAG2

Then both files will have the wanted TAG2 inserted. I think the current behaviour is unfortunate.