[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feature request/ideas

From: Derek Price
Subject: Re: Feature request/ideas
Date: Mon, 28 Feb 2005 15:19:55 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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 address@hidden' 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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]