Suppose, I have the following pattern in a comment in my code - $REV$. I would like to have a client side hook, which would replace it with something like $REV[$ d3d004be40c5 $]REV$. Any subsequent commits would assume that there is a revision between $REV[$ and $]REV$ and replace it accordingly.
I want to use a client side hook, because I do not want an extra commit for this mangling, hence it must be done on the client as part of the commit.
I reckon a precommit hook in python should be apt for the job, but I've just thought to seek for an advice before delving into it. Maybe there is a better way to do it like using an existing extension, for instance. If anyone has done anything similar - please share.
Thanks.
P.S.
I know this may seem strange to embed the revision within the source code, but please indulge me.
keyword extension does what you want (though usefulness of this is really, really low).
Related
Each time I need anything beyond the standard search, I find myself trying several things, searching Google and in the end terribly failing. Apparently, the Hg search syntax is pretty extensive and I would like to use its power, but I don't seem to be able to find a good reference.
For instance, quite often I want to find all changes in the repository related to a partial path match. I know that the following works:
file('path:full/path/file.txt')
But I would like to search for files by partial match, and neither of the following worked:
jquery -- seems to find everything
file(jquery*) -- finds nothing
file('jquery*') -- finds nothing
file('path:jquery.*') -- finds nothing
file('name:jquery.*') -- finds nothing
file('path:jquery.js') -- finds every revision, it seems
From the popup in TortoiseHg I see that there are a gazillion options, but no hint on how to use them (the help link shows a little bit more, but nothing on what a pattern should look like in file(pattern)):
In the end I usually find what I want using other ways of searching, but it would be so nice to be able to use this power of expression, and it's quite a shame that after so many years, I've never found out how to leverage this.
I can very much advise using the hg help system for this. The most useful pages to look at (in my view):
hg help revsets
hg help filesets
hg help patterns
In the page about patterns, you can find about 'path:':
To use a plain path name without any pattern matching, start it with
"path:". These path names must completely match starting at the current
repository root.
In other words: using 'path:' is not suitable for this purpose. Slightly below, 'glob:' is mentioned:
To use an extended glob, start a name with "glob:". Globs are rooted at
the current directory; a glob such as "*.c" will only match files in the
current directory ending with ".c".
The supported glob syntax extensions are "**" to match any string across
path separators and "{a,b}" to mean "a or b".
In other words, it should be possible to use the pattern file('glob:**jquery*').
In fact, the above pattern would also work without the glob prefix, so: file('**jquery*'). See part of the page about revsets:
"file(pattern)"
Changesets affecting files matched by pattern.
For a faster but less accurate result, consider using "filelog()"
instead.
This predicate uses "glob:" as the default kind of pattern.
When I run some commands, like certain scripts or Makefiles, a number of files and folders are generated along the way to the final output. (For the moment, let's not go into whether or not the script should tidy up after itself. Sometimes this might be a good idea, sometimes not.) What term describes these files?
(I know what I mean when I say "cruft", but I don't think this is necessarily clear, and it could come off as colloquial, which is not what I'm aiming for.)
A common term seems to be "intermediate files"; maybe you could say "intermediate build artefacts" if they are not necessarily just files.
CruiseControl refers to them as Artifacts at least.
I would just refer to them as ~TempFiles generated by your scripts.
I'm working on a Mercurial GUI client that interacts with hg.exe through the command line (the preferred high-level API, as I understand it).
However, I am having trouble determining the possible outputs of each command. I can see several outputs by simulating situations, but I was wondering if there is a complete reference of the possible outputs for each command.
For instance, for the command hg fetch, some possible outputs are:
pulling from https://User#server.com/Repo
searching for changes
no changes found
if there are no changes, or:
abort: outstanding uncommitted changes
or one of several other messages, depending on the situation.
I would like to structure my program to handle as many of these cases as possible, but it's hard for me to know in advance what they all are.
Is there a documented reference for the command-line? I have not been able to find one with The Google.
Look through the translation strings file. Then you'll know you have every message handled and be able to see what parts of it vary.
Also, fetch is just a convenience wrapper around pull/update/merge. If you're invoking mercurial programmatically you probably want to keep those three very different concepts separate in your running it so you know which part failed. In your example above it's the 'update' failing, so the 'pull' would have succeeded and the 'update's failing would allow you to provide the user with a better message.
(fetch is an abomination, which is part of why it's disabled by default)
Is this what you were looking for: https://www.mercurial-scm.org/wiki/MercurialBook ?
Mercurial 1.9 brings a command server, a stable (in a sense that API doesn't change that much) and low overhead (there is no need to run hg process for every command). The communication is done via a pipe.
I have an subversion server running with Apache mod_dav_svn and it works nicely but the browsing ability via HTML is a bit spartan. Is there a way to customize it at all?
There's two things I'd like to do to make a huge difference:
separate the directories from the files so all the directories are at the top. Right now everything is in alphabetical order. (the picture above happens to have all the directories preceding files in alphabetical order, but trust me, that's not the normal case)
List the basic file statistics (file size, mod time, last updated version, etc)
Is it posssible to do either of these with mod_dav_svn?
In a vanilla Subversion install, the web interface is very spartan by design. (Remember the HTTP interface is designed for SVN clients, not human beings.)
You can customize the display somewhat via the SVNIndexXSLT directive. (Here is a good place to start).
If you want something richer (with logs and diff features), you will need to install a special front end. WebSVN and ViewVC are very popular. There is also Trac, but this is a higher-level tool.
A list of other repo browsing tools.
Just FYI, we use WebSVN for our repo instance. It took some effort to get it up and running, but once it is setup you can pretty much leave it alone.
WebSvn looks like it might help you. I tried trac and it is very slick but I found it to be complicated and seems overkill for what you're looking for, imo.
Not out of the box - that is, without modifying the source code. You might be interested in tools like ViewSVN or the more sophisticated trac or redmine.
Which of the hg plug-ins has:
the least hassles
causes the least trouble
is prettiest
Can't claim to have tried a wide variety, but, what's wrong with hg4idea...?
In regards to the "don't use one" response - this is hardly adequate. What if I use my IDE to do a refactoring that renames a file? Without IDE/source control integration, the file rename is made without regards to source control, and then Mercurial (or whatever else) thinks a file went missing and a new one appeared. Then you have to go back to wrangle with the source control to sort things out.
JetBrains seems to have chosen hg4idea-luciad for its upcoming Python editor (PyCharm) and it is now more active than hg4idea
It looks like a leader is on the way :-)
To answer your question: The best IDE PlugIn is don't use on.
I think IDE integration is not necessary when working with a DVCS. When working in a centralized System, it is reasonable for the purpose of automatic check out on edit. However, I like keeping things separate. I don't want my IDE cluttered up. I don't see any benefits in using a plug-in compared to a standalone solution (that I keep running on a second monitor etc. ).
I am fine with TortoiseHG and the command line for more complicated tasks.