Yeah, my colleages have noticied this but I haven't really paid serious
attention to this.

I believe CVS does offer enough information. Sounds like I need to hack the Ant
cvs changelog parser once again.

CVS log output looks like the following:

----------------------------
revision 1.16
date: 2006/07/26 21:00:10; author: kohsuke; state: Exp; lines: +1 -0; kopt:
kv; commitid: 147c44c7d7da4eb2; filename: foo.txt;
changed
----------------------------
revision 1.15
date: 2006/07/26 20:57:00; author: kohsuke; state: Exp; lines: +1 -0; kopt:
kv; commitid: 150044c7d71c4c46; filename: foo.txt;
changed
----------------------------
revision 1.14
date: 2006/07/26 20:55:37; author: kohsuke; state: Exp; lines: +1 -0; kopt:
kv; commitid: 166c44c7d6c84b34; filename: foo.txt;
changed
=============================================================================

And '<prevrevision>' is obtained only when the "cvs log" command fetched more
than one entries from the server. The revision of the previous log record is
used as the 'previous revision' of the current log record.

Since Hudson runs "cvs log" with -d option, chances are, it only selects log
records that happened since the last build, and in that case, changelog.xml
doesn't record <prevrevision> because CVS didn't return any.

Therefore, it seems like after all it's not always possible to determine
add/edit/remove just from the CVS log command. We can distinguish remove from
other two by looking for "state: dead" line, but we can't distinguish add and
edit unless we check the previous revision.

I thought about using the output from "cvs update", but I still don't think we
can distinguish add and edit. I believe both may produce 'U' record.

Perhaps doing this correctly depends on issue #49. Then we can reliably find out
what data we are exchanging with the CVS server.

Meanwhile, I improved the parser to at least detect deletion.

Add vs. Edit is tricky because you can have a file 1.1 deleted in 1.2 and
readded in 1.3, so just checking rev.equals("1.1") will not always work. Also,
adding on a branch creates 1.1 as DEAD and a real rev 1.1.${2*k}.1 for some k>0,
and I presume readding a dead file on a branch produces some other form still.
So without a full file history it is hard to do more than guess. Since Hudson
now only asks the server for logs for files which really changed in the last
update, maybe it could leave off the -d arg to cvs log and try to extract the
important bits itself. Ugh.

Anyway I consider this a relatively low priority issue; it took me a long time
to even notice that document_add.gif was supposed to mean "added file". The file
name and log message are the important bits - if you really want to know what
changed you had better go find the diff, e.g. subscribe to the CVS change list
or have a ViewCVS server installed somewhere.

I fixed "1.1" handling. If we know "1.1" is not remove, then it's always add,
because it cannot be edit.

The rest has to wait for 49. Like you say, file names and comments are the
important bits.