-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Frank Hemer wrote:
|> | Ooops, I think I'm too fast;-) I have just finished adding |> '.trunk' | as a trunk-branch substitution, 'cause I happened to |> note that this | fits perfectly into my patch. I have already |> used the above | mentioned splitting - so now '.prev' might even |> be added more than | once and works perfectly well:-) |> |> Great! Less work for me. :) | | | You could do me a big favor if you later would add some test cases | to sanity.sh ...
We'll see when the time comes, but I'm not going to have a whole lot of free time for a few weeks at least, unfortunately.
|> |> I still think commitids should be cached in val-tags. |> Probably |> as [EMAIL PROTECTED]' just to keep it short where the user |> cannot see it |> anyhow. | | I currently have added this: | | If |> tags with '@' at the begining are used they're added in the | |> cvsnt way (I remember I wrote cvsnt wouldn't cache them but I was |> | wrong). If the .commitid is used, they're cached as | |> '.commitid.xxx', but this could be changed as you suggested. |> |> I think this would be a good idea, as otherwise the search of |> val-tags will be run once for each possible form of the commitid. |> | | | So I need a suggestion, cvsnt seems to cache the whole commitid, | for example: '@123f456a789b' or even worse: '@<123f456a789b' | | probably its best to change it all to '@commitid'?
Ah, now that's interesting. I think the answer is yes, though.
The issue is whether a commitid attached to revision 1.1, which has no previous revision, should return an error when @<commitid is requested. I think the answer is no, since I would assume that a user would want `cvs diff -r@<commitid @commitid' to return something useful for a file added in the commit in question.
|> Also, commitids should be cached at commit time as well as when |> they are found in RCS files. CVS started doing this on tag |> creation for other branches and tags a few releases back It's |> silly to wait for the first update to insert them into val-tags - |> it only triggers an unneeded recursive search. | | | I saw tag.c::tag_check_valid(). Are there other locations where | val-tags entries are added/accessed?
No, that is the only location. The trick is that you need a call like `tag_check_valid ("@commitid", 0, NULL, 0, 0, NULL, true);' in commit.c after you are certain that the commitid has been added to at least one file. Should only call it once per commitid too, if possible.
Cheers,
Derek -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCI3zqLD1OTBfyMaQRAi2HAKCk5sVmyK+1LK2NQBFFZkO2ukT6iQCbB6/o W6VueNoHjoZl68xjTLOYLSc= =Ti6e -----END PGP SIGNATURE-----
_______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs