I have made a build system for my web application that's rewriting all resource url's to include the file's revision number (to improve client caching). As of today I'm running this command for each file to get the revision number:
hg log --template '{rev}\n' path-to-file
Executing hg for each file is really time consuming. Is there a fast way to list all fil开发者_如何学Ces in a repository with the latest revision number?
This will do it, but please see my comment above as to why using this anywhere in your workflow is probably a bad idea. At the very list you should be using the revision hash not the number, since that doesn't change on clone. Also this isn't terribly efficient, but at least it's only two process instantiations instead of one per file:
hg grep --all '.' | perl -na -F: -e 'next unless ($F[2] eq "+"); print "$F[0] $F[1]\n" unless ($prev eq $F[0]); $prev = $F[0]'
Example:
that 3
file 1
There is a hg debug command "hg debugdata -m REV" which might help you. Below is how it work:
- I commit 3 files a.txt/b.txt/c.txt in changeset 0/1/2/, respectively. And I modify a.txt in rev 3. The DAG looks like this:
------- 0 -------> 1 --------> 2 -------> 3
a.txt b.txt c.txt a.txt
So the newest rev for a/b/c should be 3/1/2;
After that , the log records are:
hg log -q
3:31308f74291a 2:8d438b01dfd4 1:fcc0f041df56 0:c53934933136
a.txt has two versions, which is linked to changeset 0 and 3 respectively. For every version of a.txt, mercurial will generate a unique hash(nodeid) for it. These nodeid pertains only to a.txt, and are different from changeset hash. We can use another debug command to see what are those versions:
~/work/hg/a/.hg/store/data$ hg debugindex a.txt.i
rev offset length base linkrev nodeid p1 p2 0 0 3 0 0 b789fdd96dc2 000000000000 000000000000 1 3 6 1 3 a9ecbd92f818 b789fdd96dc2 000000000000
We can see these two "nodeid" (b789fdd96dc2/a9ecbd92f818) corresponds to changeset version (linkrev) 0/3 respectively. Since these nodeid are hashed based on file contents and parent information(p1/p2), they are "unique" in repository sense. so "b789fdd96dc2" identify a.txt@version-0, and a9ecbd92f818 identify a.txt@version-3.
- Finally, let us see how "hg debugdata -m REV" work.
This command list a "manifest" of version REV. A manifest is a directory snapshot for all the file@version that exist in specific changeset REV. Let us see what the manifest is at version 3:
~/work/hg/a$ hg debugdata -m 3
a.txt^@a9ecbd92f8182efd8eeb5396468fd70884650395 b.txt^@1e88685f5ddec574a34c70af492f95b6debc8741 c.txt^@149da44f2a4e14f488b7bd4157945a9837408c00
For a.txt, you can see its nodeid is "a9ecbd92f8182efd8eeb5396468fd70884650395", which is a match for the short version nodeid mentioned at step 3. Such nodeid should serve your "rewrite URL" well.
Now you have text name and their nodeid at revision 3. It only take one debug command to generate all you want. I think this is a better solution.
If you are interested in the debug commands that mercurial provides, do this:
hg debugcomplete debug (list all debug commands)
hg help debugdata
hg help debugindex
Coding such a command in python, either by parsing hg annotate or as a mercurial extension should not be too difficult. The following discussion on the mercurial mailing-list seems to provide a reasonable solution, although I have not tried it.
精彩评论