The RSS feeds are a very good way to keep people updated about the latest changes in a repo. Unfortunately, the default RSS feeds include only the commit message in the body.
This similar question has information on how to customize the feed, but unfortunately there is no mention of adding a diff. Is it at all possible? How can I do it?
As it turns out, not only the {diff} is not passed to the changelogentry.tmpl for RSS, but the RSS template set itself is lacking some templates needed to display diffs.
I've done a quick-and-dirty patch adding raw diffs to the Mercurial RSS template set. The patch is based on the version 2.2.1 of Mercurial. It modifies the Mercurial source (webcommands.py) in addition to the RSS template set, so you'll end up using a patched version of Mercurial itself, not only the templates.
The patch can be found on the so-10796514 branch in my copy of the Hg repo on Bitbucket. Feel free to use it.
Here's how the modified changelog looks like on my machine:
I guess it can be improved from this point on.
Related
Is there any way I can copy the current change list to a text file in every commit?
I am using Mercurial HG, and an ASP.NET MVC and SQL-based web project. If this is possible, then I can always check the current change list by just checking the text file.
Any thoughts on this? Any other idea to achieve this?
It's a bit hard to get your question but I believe patches are what you're searching for.
You can create a patch in every source versioning software (hg/git/svn/etc.).
If you want to do that automatically on each commit, do a hook (this is also supported by all the source versioning softwares).
If you just want to check the changes, simply try the diff command (e.g., hg diff) that dumps the diff of the current changeset to the console. You can redirect it to a file too. There are some nice GUI tools for that (e.g., git gui for git).
Our team of 4 currently uses svn, but I am testing out Mercurial. We code mostly in C++ and C# on .net. I have installed TortoiseHg, and use hgsubversion to push/pull against the existing svn repo. Other developers on the team will remain on svn for now.
I tend to have a few source files that I have customized (butchered would be a better term) in some specific way that I don't want to push to other developers. But I do want these custom changes compiled into my version of the project. The ratio of normal files to customized files is about 100:1
What is the best way to deal with these butchered files in mercurial? I could simply uncheck butchered files during commits, but eventually, I will forget this step. I have taken a brief look at shelving and ignoring.
Ignoring doesn't seem right, because these are tracked files. I do want to pull changes to butchered files from others. Shelving was close, but it removes the butchered code from my working copy, so that isn't correct either.
I can't be the only code butcher out there. Let me know how you deal with this. Git users, we are happy to hear from you too, we haven't entirely committed to using hg.
If they're files most everyone will be modifying (per developer database account info, etc.) the right way to do it is by tracking a xxxxx.sample file. For example have the build script use local-database.config which is in the .hgignore and provide a local-database.config.sample file in the repository. You can either include "copy the sample to the actual" in your instructions or have the build script do it automatically if the actual doesn't already exist. We have our config do a include of settings.local if and only if it exists, and allow it to override main settings. Then no one needs a local config, but it can be optionally used to alter anything w/o a risk of committing it.
If they're files that only you will be modifying the best way is to learn Mercurial queues. Then you can pop that changeset with the you-only changes, push to central repo, and then apply it again for your builds. There are various extensions that do similar things (shelve for example), but mq is preferable because you can version the overlay you're popping and applying.
I would like to embed some version information on top of my source code file with information such as version number, author, and date of edit.
Is there a simple way to do this with Mercurial?
This has been asked a lot here on Stackoverflow and the short answer is: you shouldn't do it.
You don't want a file that changes with every commit it makes merging a nightmare.
Better options are:
write the version string to a file on update
have you build/deploy script run $(hg id) and put that into the build at that time
Trust me, revision strings in files is CVS/SVN thinking. It has no place in a git / Mercurial world.
As comments and other answers mention, it is not a good idea to rely on CVS-like, automatically expanded, tags. Specially since you can extract whatever meta-information you need at any time and almost any granularity afterwards.
However, if you really need it (because your boss says so, for instance), the closest you can get is by making use of the keyword extension that comes bundled with mercurial.
My favorite way is to use the hgversioninfo plugin.
It generates a version.py file on the fly on "hg commit", "hg update", etc.
Yes it is possible, but you need to enable it. What you are asking for is basically the keyword extension. Be careful when enabling this the first time (read the section about kwshrink, kwexpand), because you wouldn't want the actual expanded keywords to become part of the revision history.
This is not quite a specifc question, and more me like for a criticism of my current approach.
I would like to include the program version number in the program I am developing. This is not a commercial product, but a research application so it is important to know which version generated the results.
My method works as follows:
There is a "pre-commit" hook in my .hg/hgrc file link to version_gen.sh
version_gen.sh consists solely of:
hg parent --template "r{rev}_{date|shortdate}" > version.num
In the makefile, the line version="%__VERSION__% in the main script is replaced with the content of the version.num file.
Are there better ways of doing this? The only real short coming I can see is that if you only commit a specfic file, version.num will be updated, but it won't be commited, and if I tried to add always committing that file, that would result in an infite loop (unless I created some temp file to indicate I was already in a commit, but that seems ugly...).
The problem
As you've identified, you've really created a Catch-22 situation here.
You can't really put meaningful information in the version.num file until the changes are committed and because you are storing version.num in the repository, you can't commit changes to the repository until you have populated the version.num file.
My solution
What I would suggest is:
Get rid of the "pre-commit" hook and hg forget the version.num file.
Add version.num to your .hgignore file.
Adjust version_gen.sh to consist of:
hg parent --template "r{node|short}_{date|shortdate}" > version.num
In the makefile, make sure version_gen.sh is run before version.num is used to set the version parameter.
My reasons
As #Ry4an suggests, getting the build system to insert revision information into the software at build time, using information from the Version Control System is a much better option. The only problem with this is if you try to compile the code from an hg archive of the repository, where the build system cannot extract the relevant information.
I would be inclined to discourage this however - in my own build system, the build failed if revision information couldn't be extracted.
Also, as #Kai Inkinen suggests, using the revision number is not portable. Rev 21 on one machine might be rev 22 on another. While this may not be a problem right now, it could be in the future, if you start colaborating with other people.
Finally, I explain my reasons for not liking the Keyword extension in a question of mine, which touches on similar issues to your own question:
I looked at Mercurials Keyword extension, since it seemed like the obvious solution. However the more I looked at it and read peoples opinions, the more that I came to the conclusion that it wasn't the right thing to do.
I also remember the problems that keyword substitution has caused me in projects at previous companies. ...
Also, I don't particularly want to have to enable Mercurial extensions to get the build to complete. I want the solution to be self contained, so that it isn't easy for the application to be accidentally compiled without the embedded version information just because an extension isn't enabled or the right helper software hasn't been installed.
Then in comments to an answer which suggested using the keyword extension anyway:
... I rejected using the keyword extension as it would be too easy to end up with the string "$Id$" being compiled into the executable. If keyword expansion was built into mercurial rather than an extension, and on by default, I might consider it, but as it stands it just wouldn't be reliable. – Mark Booth
A don't think that there can be a more reliable solution. What if someone accidentally damages .hg or builds not from a clone but from an archive? – Mr.Cat
#Mr.Cat - I don't think there can be a less reliable solution than the keywords extension. Anywhere you haven't explicitly enabled the extension (or someone has disabled it) then you get the literal string "$ID$" compiled into the object file without complaint. If mercurial or the repo is damaged (not sure which you meant) you need to fix that first anyway. As for hg archive, my original solution fails to compile if you try to build it from an archive! That is precisely what I want. I don't want any source to be compiled into our apps without it source being under revision control! – Mark Booth
What you are trying to do is called Keyword Expansion, which is not supported in Mercurial core.
You can integrate that expansion in make file, or (simpler) with the Keyword extension.
This extension allows the expansion of RCS/CVS-like and user defined keys in text files tracked by Mercurial.
Expansion takes place in the working directory or/and when creating a distribution using "hg archive"
That you use a pre-commit hook is what's concerning. You shouldn't be putting the rest of version_gen.sh into the source files thesemves, just into the build/release artifacts which you can do more accurately with an 'update' hook.
You don't want the Makefile to actually change in the repo with each commit, that just makes merges hell. You want to insert the version after checking out the files in advance of a build, which is is what an update hook does.
In distributed systems like Mercurial, the actual "version number" does not necessarily mean the same thing in every environment. Even if this is a single person project, and you are really careful with having only your central repo, you would still probably want to use the sha1-sum instead, since that is truly unique for the given repository state. The sha1 can be fetched through the template {node}
As a suggestion, I think that a better workflow would be to use tags instead, which btw are also local to your repository until you push them upstream. Don't write your number into a file, but instead tag your release code with a meaningful tag like
RELEASE_2
or
RELEASE_2010-04-01
or maybe script this and use the template to create the tag?
You can then add the tag to your non-versioned (in .hgignore) version.num file to be added into the build. This way you can give meaningful names to the releases and you tie the release to the unique identifier.
What's the best way to move a Visual Sourcesafe repository to Mercurial (I'm interested in retaining all history)?
While I haven't made that particular conversion, I have gone from VSS to SVN using (IIRC) this script. You'll probably want to look into tailor and do a search for vss2hg. Also keep in mind that it may make sense to go through an intermediate step like vss2svn + svn2hg or similar.
The primary bit of advice I'd give though is: script the conversion so you can re-run it easily. That will let you run nightly conversions from VSS to Hg and make sure that everything is converting correctly before you pull the trigger on it.
I am the author of the vss2hg.pl script and have used it to move many projects from VSS to Mercurial. It has one or two minor bugs where some comments are not completely converted but I haven't seen any other issues. It converts complete history and works-around a problem with VSS where a user's PC clock can affect the order in which changes appear to be made.
A version of the script is available here.
I used the vss2hg.pl script from here. It is a Perl script, so you need to install ActivePerl first.
It worked great, but I ran into a problem with the dates. It turns out that the script supports three kinds of date formats. By default it is set to the UK date format (in line 547). The other two date formats are commented out in the code. After enabling the US date format, the script converted my SourceSafe database without a problem.
The Mercurial wiki has this page, which might be of interest: https://www.mercurial-scm.org/wiki/SourceSafeConversion. I've never used Visual source safe, so I don't have any personal experience with it.
I also found a mail from Patrick Mézard about the subject, but unfortunately he writes that a VSS converter will be difficult. He also talks about converting to Subversion first, and then from Subversion to Mercurial. I guess that means that there are VSS -> SVN converts out there. You can probably google that yourself.
I have done a conversion from SourceSafe to Mercurial for a client. I first converted the SourceSafe database to a Subversion repository and then from Subversion to Mercurial using the hg convert extension. See my blog post for details.
I just tried using vss2hg and ran into a problem that it only pickup up and converted 1 user. This means all my changesets etc will not be accurate as I won't be able to see who did them. Is this because I've not pre-setup all the required users in hg?