Re: Feature request/ideas

[Derek Price]

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


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-----