Re: Feature request/ideas

[Frank Hemer]

> | 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 `@commitid' 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