[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: Sat, 26 Feb 2005 15:06:04 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hash: SHA1

Frank Hemer wrote:

| On Saturday 26 February 2005 00:27, Derek Price wrote:
|> Frank Hemer wrote: |> I was just glancing at that patch and I
|> think I can implement |> what Steve did much more succinctly, so
|> I'm going to take a shot |> at it. The most important thing for
|> your patch is probably to use |> the naming scheme: `.XXX'. | |
|> So I'll wait for your commit then.
|> Here's a question:  Should the commitids be cached in
|> CVSROOT/val-tags in some form?  I think so.  What is CVSNT doing
|> in this regard?
| Cvsnt seems not to cache the commitids. I don't think it is
| reasonable to cache here because _every_ commit would be cached,
| bloating val-tags but not gaining any performance.

Actually, the trick with val-tags is that it is much cheaper to search
the dbm file than it is to parse and search each and every RCS file
when looking for a tag that may only exist in a single file.  Even
with a lot of commits, it will remain cheaper to search the val-tags
file, I would hazard.

Though it's not yet being done, the current recursive RCS file tag
search could be made more efficient by only parsing the RCS header
when validating tags.  This won't work with commitids, since they are
stored with the revision data, adding more reason for adding them to

It's possible that if DBM search performance ever becomes an issue, we
could move to some sort of sorted (and indexed? binary?) dbm type that
is cheaper to search.


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]