> | 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 ... > |> 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'? > 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? Regards, Frank -- - The LinCVS Team - http:/www.lincvs.com _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
