Re: lines modified in newly-added files

[Derek Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Conway wrote:

| On Tue, 2005-02-15 at 12:41 +1100, Neil Conway wrote:
|
|> I would like to see "lines: +3 0" associated with revision 1.1.
|> It is possible to get the number of lines modified via a kludge
|> (fetch the 1.1 revision of the file and manually count the number
|> of lines in it), but I think it would be reasonable for CVS to
|> provide this information itself.
|
|
| Any comments on this?
|
| How about this revised behavior:


This is an interesting idea, but you may have to completely rework the
way CVS determines these values.  Currently, CVS counts and inverts
the number of add and delete ops in the change text of the previous
revision in the RCS file to get these values, on the head.  (CVS
stores only the full text of the HEAD revision in the archive, then
stores diffs from the previous revision in the archive.  Thus, in a
file with 3 revisions, revision 1.2 may say it adds five lines and
deletes three from the HEAD to get there - therefore, it would be
adding three lines and deleting five in the other direction.)

On branches, CVS needs to use the real count since the change texts
start going forward again.  For a branch off rev 1.2, CVS needs to
start with the head revision, back up to revision 1.2 from there, then
apply diffs forward to the 1.2.x.y revision.

With removed and readded files, the count shows up as +0 -0 because
CVS stores no diffs at all for these.  The revision "content" is the
same, but CVS sets a state flag on the removed revision to "dead".
Thus, there is no actual change text in a diff for removed files, and
indeed, possibly not for readded files, unless the readded file is
different from the version which was deleted.

These counts are tracked and stored in RCS_fully_parse as each
revision text is processed and stored in a vers structure.  The number
of lines added and removed to get from revision 1.3 to revision 1.2 is
stored as part of the vers structure for revision 1.2.  Then `cvs
log', while it is processing revision 1.3, grabs the count from
revision 1.2 and inverts it to get the count going from 1.2 to 1.3.

This last means that even if you determine the number of lines in
revision 1.1 in RCS_fully_parse, you wouldn't have anyplace to store
it in the current structure, as the ;add and ;delete values in
revision 1.1 are already filled with the count of changes to get from
1.2 to 1.1.

I think this can be done by creating a new ";total" data field
attached to each revision.  You will need to count the total number of
lines in the HEAD revision and keep it up to date as added and deleted
lines for other revisions are processed.  Later, in `cvs log', these
new fields should be usable in conjunction with added and removed
lines to get the output you are after.

Therefore, to comment on each of your bullet points:

| - a file addition is treated as adding the the number of lines in
| the new file's content


Whatever ";total" you have left when you get to revision 1.1 will be
your initial added value.  Print it out in the +X position.

| - a file removal is treated as removing the number of lines that in
| the old file's content, prior to deletion; this does _not_ include
| any bogus "additions" due to keyword substitution in the deleted
| content


When you hit a removed file, the ";total" field of the previous
revision (e.g. 1.2 if 1.3 is removed) should be the count of removed
lines for output.

| - re-adding a file is treated the same as an addition from scratch;
| we only count the number of lines in the new content, not the diff
| between the file's content prior to deletion and it's new content
| (this is on contrast to CVS's present behavior, which does the
| latter)


When you hit an added file, ";total" should be the number of lines
readded.

| The first bullet point is all that really matters to me; the rest
| is just for the sake of consistency.
|
| I realize there may be backward compatibility concerns; this would
| naturally only be in the feature release series.


Cheers and good luck.  I'm looking forward to seeing a patch.

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCGeHoLD1OTBfyMaQRAhQfAJ9kwt4J1fU8oT5uVVStkCSQubIZ5wCgpgKG
OQGkGoCTEeU+AnuWR9EfqSw=
=Aiat
-----END PGP SIGNATURE-----