[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 12:08:01 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hash: SHA1

Frank Hemer wrote:

| On Saturday 26 February 2005 21:06, Derek Price wrote:
|> 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.
| Well, actually the commitid isn't a tag ... However, I added it in
| tag.c::tag_check_valid() to play around ...
|> 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 val-tags.
|> 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.
| Good Idea, this would open ways to implement a real 'rename' and
| 'move' feature ...
| I have pasted my current patch state, there is no docu yet, and no
| sanity.sh testing. However, the current sanity.sh is not affected
| by the patch, and still runs ok.
| Features: 1) .commitid.xxx will select the revision when used as a
| tag 2) appending '.prev' to a numeric revision or a symbolic tag
| will select the previous revision
| Probably more testing needs to be done, but I'll wait for feedback
| ... Unfortunately my mail-client refuses to switch of line
| wrapping, but I'll care about it another time:-(

The patch looks pretty good.  It's pretty close to what I am doing,
except I am splitting tags with operators (.word) on the `.' and then
processing the resulting list an element at a time.  Thus .prev can be
implemented for each and every revision specification type in a single
location (as opposed to in a special case inside an `if (commitid)' block.

Regardless, what you are doing should mesh pretty well with what I am
working on once it has sanity.sh test cases and doc.

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.


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]