Thomas Arendsen Hein wrote:
* Richard Lowe <[EMAIL PROTECTED]> [20061025 14:36]:
Bill Shannon wrote:
Rich tried this and I futzed with it a little bit; we tried using
encode/decode filters - but I believe it would slow down pulls/clones
incredibly as it would have to transform each and every single file on a
pull/clone/push. I think Rich expressed this same concern.
If you use the RCS keyword approach I think you only pay when you
do a commit.
On commit (low overhead) and on update/checkout, but definitely not
on pull/clone/push.
I was under the impression the update hook ran when populating the
workspace during clone, also. (and if it didn't, surely this would
leave keywords unexpanded immediately after clone?)
In reference to Steve's question, no, I didn't do any timings of expand-on-update, while I hate to
use the phrase without timings, it seems 'obvious', that expanding the keywords in each and every
file on clone is going to be slower than not doing so, after that I would expect near equivalence.
In general this is something I've been meaning to ask the mercurial list (who I happily see are
Cc'd) about.
Mercurial folk, is there a hook I'm not seeing that would allow for
RCS-like keyword/ident string expansion on commit?
The recipe on the mercurial wiki seems to rely on a bug where the dirstate gets confused by such
shenanigans (this is from rather old memory, please correct me if I'm wrong here).
You remember correctly.
The decode/encode filters should be the right place for this, though
I don't know for sure if Mercurial provides them with all needed
information yet (i.e. the current changeset hash).
A quick glance suggests we don't even get the filename being filtered,
just a raw input stream.
You can circumvent performance problems by using a python extension
instead of shell skripts with decode/encode. Look at
hgext/win32text.py and contrib/win32/mercurial.ini for examples.
I see in-process python hooks, but not filters. Are these more recent
than 0.9.1 or am I missing something?
Currently decode/encode has the problem that you can only use one
filter and not combine e.g. CR/LF conversion, gzip compressed
working files and keyword expansion without creating a
one-size-fits-all filter.
The other issue in this area would be getting the hook/filter to each
and every child workspace, since such things don't propagate on clone.
-- Rich
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
