I'm using Workbench, but if there's a command line solution for this or some extension, I'm open to that as well.
I'm constantly working in config files per environment (working in .NET, so please no answers a la "change your config files" etc) and at times I need to commit specific updates to the file. I've seen this behavior in Github for Mac client, but is anything like this available in Mercurial/Workbench? e.g.
web.config
config value="123"
whatever blah blah
change both lines e.g.
config value="42"
whatever
My goal is to commit only line 2 (whatever) while not committing line 1 (config value="42")
You probably need RecordExtension which is shipped with Mercurial but has to be enabled to be used.
The Record Extention isn't up to the job in this case. It will lump the two changes into a single hunk which you can include or not, but it won't allow you to split them.
What you need is the CRecord Extention, as that allows you to select individual lines. It's also a nicer interface.
Edit: Since writing this, Record and CRecord have been folded into core. commit -i is now equivalent to record, and if you add this to your .hgrc the record commands will use the nicer interface.
[ui]
interface=curses
hg record ou hg commit -i will do the job, but you have to use the e command in order to manually edit the patch.
In your case, you will have to replace:
-config value="123"
-whatever blah blah
+config value="42"
+whatever
to
config value="123"
-whatever blah blah
+whatever
It is not the best UI, but it does the job.
Related
We are looking for a way to add / update a custom tag at the beginning of each file being committed during a commit. Its some kind of local timestamp we need.
I was thinking of hooks.
Unfortunately I cannot find a useful hook for that:
precommit: unsuitable as it fires before hg knows any metadata of the commit
pretxncommit: unsuitable, as the documentation clearly states that we should not change the working dir at this point
commit: unsuitable, as it fires when the commit has already happened.
EDIT:
I can not use hg's inline changeset-hash and / or datetime. For the following reason:
Our files get later imported into an external system (we do not have control over) which does not support any kind of versioning.
To simplify stuff: let's say tag is an ever-incrementing no. (everytime we commit). This tag is then used to help getting an idea of the version / status of the file on the system in respect to the file in the repo - like "no. of changes we're missing" and such.
Any ideas?
I would suggest a two-stage solution. First, create an alias along the following lines:
[alias]
tcommit = !tag-changed-files && $HG commit "$#"
Here, tag-changed-files would retrieve a list of modified and added/moved files via $HG status -ma -n or $HG status -ma -n -0 and tag them. I am assuming that re-tagging files that have been modified but aren't being committed yet is a harmless operation; more on that below. Note that you can even redefine commit if you absolutely want to via:
[alias]
commit = !tag-changed-files && $HG --config alias.commit=commit commit "$#"
However, this is potentially problematic, because it may confuse scripts.
You could also integrate the commit step in the program if you wanted to, and even try and parse the command line arguments to only tag those files that you are committing. For this approach, using hglib might be appropriate to avoid the overhead of invoking Mercurial multiple times. (Note that hglib and other tools that use the command server ignore aliases and command defaults, so this works even if you alias commit).
Second, you'd install a pretxncommit hook that verifies that files that are being committed have indeed been tagged appropriately (to ensure that the tag-changed-files program hasn't been bypassed by accident).
This should work without a problem on full commits; for partial commits, any files that were changed but have not been committed would also have been retagged, but since they will be either committed later (and get tagged properly at that point) or reverted, that should be harmless.
an idea of the version / status of the file on the system in respect to the file in the repo
Just one idea
Stop reinvent the wheel
Incremental counter is just shit, if you task is "to know, which version is on LIVE and which - in Mercurial's tip" (and this is your real business-task, yes?!)
Keyword Extension give you last changes per file.
If you want to inject changeset of repository into files (it's reasonable good way), re-read this part of wiki-page
If you just want to version your entire repo, do not use this
extension but let your build system take care of it. Something along
the lines of
hg -q id > version
before distribution might be well enough if file-wise keyword
expansion in the source is not absolutely required
You can insert hg id output into files at export stage (in planetmaker's sed-style), bu you can also have this additional metadata in files permanently in VCS with special encode|decode filters
There is - to my knowledge - no intrinsic system in mercurial which supports what you describe. However I can recommend an approach which somewhat is adopted from building a software release package from the repository: Make a small export script which replaces a certain KEYWORD in your files with the version information you need. A Makefile target could look like which creates a zip export for revision XXX with version information in all files which support it (thus contain the verbatim KEYWORD - use something truely unique here):
VERSION=$(hg log -rXXX --template="Version: {node|short} from {date|isodate}")
export:
hg archive -rXXX -t files export
for i in $(hg ma -rXXX); do sed -i "s/KEYWORD/$VERSION/g" $i; done
zip -9rq export.zip export
I use a similar approach in my Makefiles where I create versioned export for the source of a particular revision of my software.
EDIT: if your purpose (as stated by the comment) is only to implant the number of commits made to that file: then you can use indeed a pre-commit hook and modify the file. You can count the number of modifications made to a file with hg log FILENAME --template="{node}\n" | wc -l. Do that for every file and do the sed replacement in the header of each file in the pre-commit hook.
In an effort to boost code reviews, I am looking to send a daily/weekly/monthly/some_regular_interval report of changes from mercurial? I figure that if a person does not have to go and find the changes, but they are instead brought to the person, then that should be a step in the right direction. However, I did not see anything already out there. (We use mercurial with TortoiseHG and Jenkins for the automated build in case any of those tools might help?)
What I am looking for:
MUST HAVE
commit message
list of files that changed
NICE TO HAVE
changeset guid
name of person who did the commit
some means to see what changed on each file (probably best via a URL or else the email could become overloaded)
You don't state what OS you are using. I am assuming Windows since you are using TortoiseHG.
On Linux (or other UNIX-based OS) you can create a cron that runs once a week/month/whatever. The following simple script satisfies most of your requirements on my Linux machine:
LOG_DATE=`date -d "1 week ago" +"%Y-%m-%d 00:00:00"`
hg log -d ">$LOG_DATE"
If you use Mercurial templates you can get exactly what you want. You can construct a URL using the changeset ID to point to a Mercurial web-server.
Would the notify extension work? You can configure this on a designated master repository so that emails with a summary of the changes (you can customise the template to include the short form of the hash, the user name, the commit message) along with URLs to the individual changesets are sent out to people whenever changese are pushed to the master repository.
We use tortoise hg with Kiln. In my vs 2010 c# project there are some files that are part of the repository but I would like tortoise hg to ignore them when I make a commit.
For eg., say in a login screen I may hard code the userid, password for testing. I dont really want this file considered during a commit. I understand .hgignore file but this really works for files that are not part of the repo. Any trick in tortoise hg to ignore files that are part of the repo ? (so they do not show up as modified (M) during a commit.) thanks
I always use a combination of .hgignore and BeforeBuild (in the .csproj file) for things like this.
In one of my pet projects, I have the following setup:
App.config contains my real hardcoded user id and password for testing.
App.config.example is identical, but with fake data like "dummy_user" and "dummy_pw".
App.config is not part of the repository, and it's ignored (in .hgignore).
App.config.example is part of the repository.
Then, I have the following in the BeforeBuild target in the .csproj file of my solution:
<Target Name="BeforeBuild">
<Copy
Condition="!Exists('App.config')"
SourceFiles="App.config.example"
DestinationFiles="App.config"/>
</Target>
All this together has the following effect:
the config file with the real data can never be accidentally committed to the repository, because it's ignored
the repository only contains the config file with the example data
if someone else clones the repository to his machine, he won't have the "real" config file...but if it's missing, it will be automatically created before the first build by Visual Studio / MSBuild by simply copying the .example file (and then he can just put his real login data into the newly created App.config file).
if an App.config with real hardcoded user data already exists, it won't be overwritten when building because the BeforeBuild event will only happen if App.config does not already exist
The answer by Christian is the right one, but I want to mention that TortoiseHg supports what you want with their Auto Exclude List.
One problem with an exclude list is that it cannot work with merges: you must commit all files when you merge and so you'll have to do a little dance with shelve, merge, commit, and unshelve.
When you do a TortoiseHG commit, there is a list of files with checkboxes by them. Deselect the files you do not want comitted.
Or, on the command line, do a commit of the form hg commit --exclude "pattern", where pattern is defined in the hg man page.
You could always use hg forget.
I have a "central" repository that I want to ensure that no one pushes changes in to with a wrong user name.
But I can not figure out how to make a hook that tests the user name against a positive list. I have found in the Mercurial API a ctx.user() call that seems to be what I want to test my positive list against.
Also the hook could be a precommit hook that is distributed as part of the repository clone or it could be a hook on the central repository as a pre-incoming or something like that.
Any help or pointers would be greatly appreciated.
I have posted two functional examples on Bitbucket. Both examples are for searching a commit message for some specifically formatted text (like an issue tracked case ID), but could be easily modified to check a user against a list of valid users.
The first example is actually a Mercurial extension that wraps the 'commit' command. If it fails to find the appropriate text (or valid user in your case), it will prevent the commit from occurring at all. You can enable this in your .hgrc file by adding these lines:
[extensions]
someName = path/to/script/commit-msg-check.py
The second example uses a in-process pretxncommit hook, which runs between when the commit has been made, but before it becomes permanent. If this check fails it will automatically roll back the commit. You can enable this in your .hgrc file by adding these lines (assuming you kept the same file/function names):
[hooks]
pretxncommit.example = python:commit-msg-check-hook.CheckForIssueRecord
You can execute any Python code you like inside of these hooks, so user validation could be done in many ways.
Thanks for the examples dls.
In the end I decided to run it as a pretxnchangegroup hook and then use the hg log and grep to test the author field of the commits:
[hooks]
pretxnchangegroup.usercheck = hg log --template '{author}\n' -r \
$HG_NODE: | grep -qe 'user1\|user2\|etc'
It does of course not provide a very good feedback other than usercheck failed. But I think it is good enough for now.
I am trying to do "continuous integration" with TeamCity. I would like to label my builds in a incremental way and the GUID provided by the VCS is not as usefull as a simple increasing number. I would like the number to actually match the revision in number in Mercurial.
My state of affairs:
Mercurial info:
I would like the build to be labeled 0.0.12 rather than the GUID.
Would someone be so kind and save me hours of trying to figure this out ?
As Lasse V. Karlsen mentioned those numerical revision numbers are local-clone specific and can be different for each clone. They're really not suitable for versioning -- you could reclone the same repo and get different revision numbers.
At the very least include the node id also creating something like 0.0.12-6ec760554f2b then you still get sortable release artifacts but are still firmly identifying your release.
If you're using numeric tags to tag releases there's a particularly nice option:
% hg log -r tip --template '{latesttag}.{latesttagdistance}'
which, if the most recent tag on that clone was called 1.0.1 and was 84 commits ago gives a value like:
1.0.1.84
Since you can have different heads that are 84 commits away from a tag in different repos you should still probably include the node id like:
% hg log -r tip --template '{latesttag}.{latesttagdistance}-{node|short}'
giving:
1.0.1.84-ec760554f2b
which makes a great version string.
The best and easiest way to see rev. number in TeamCity build number is to use Build Script Interaction with TeamCity. Namely, it has a possibility to set Build Number.
So, add to your project a new very first build step Command Line with following Command Executable
for /f %%i in ('c:\tortoisehg\hg id -n') do echo ##teamcity[buildNumber '%%i']
And you will get the Mercurial revision number as a label for your every build.
Of course you can change the command in quotes to anything you wish.
I believe my answer is way more correct than the accepted one.
EDIT:
Also you can do the same via MSBuild task rather than Command Executable. Have a MSBuild project file with following code, setup TeamCity to run it as first step, and it will alter its global variable buildNumber:
<Message Text="##teamcity[buildNumber '$(CurrentVersion)']" Importance="High" />
Where CurrentVersion is a string containing full version (for example "1.0.56.20931").
hg id produces the hash (6ec760554f2b), hg id -n produces the local revision number (12).
(Note this is an answer purely from the hg side, how you then get that into TeamCity, I don't know, as I've never used it.)
I managed to use it in Teamcity using a workaround:
<Exec Command="hg log -r tip --template {latesttag}.{latesttagdistance} > $(BuildAgentTempDir)\version.txt"/>
<ReadLinesFromFile File="$(BuildAgentTempDir)\version.txt">
<Output TaskParameter="Lines" ItemName="versionInfo"/>
</ReadLinesFromFile>
<TeamCitySetBuildNumber BuildNumber="#(versionInfo)-{build.number}" />
If you see the MSBuild task "TeamCitySetBuildNumber" I'm using the "{build.number}" variable because it substitutes this with what you set in the build number originally. I used %build.vcs.number% in my original settings (in the Web UI) and the result is just what Ry4an wrote above!
Hope it works for you!
When I used to use Subversion I used to do something similar in TeamCity. The format was:
{Major}.{Minor}.{TeamCity Build No.}.{Subversion Revision No.}
This allowed me to look at an assembly and see which build it came from on TeamCity and the revision number from subversion.
I have now moved to Git which has put me in the same situation as you. After playing with various ideas I have come to the conclusion that I don't actually need the revision, the build is good enough. Because TeamCity is such a powerful tool, all you need is the build number, given the build number you can look at the build history and determine the revision from that.
{Major}.{Minor}.{Macro}.{TeamCity Build No.}
Additionally you can get TeamCity to label your repository with the build number allowing you to look up a given build in your source control.
When providing your build number with numeral mercurial revision, you must be aware, that those numbers are clone-specific and can differ from clone to clone.
In our project we had the same issue. We're using TeamCity 7.1.1. We solved it in the following way:
Add Command line build step to your configuration.
Make this build step run first.
In the build step properties select "Run: 'Executable with parameters'"
Add the following text to Command Executable:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%%i']
Save changes.
You can also use previously generated build number when performing step 3.
Example:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%system.build.number%.%%i']
You can use this to make build counter present in your build number.
Read this to get more information!
Remember that teamcity compiles configurations build number before build starts and the correct build number will appear only after your build step will finish its job. That's why, in some cases (f.e. inserting your mercurial revision into artifact's name) you should define build number's value in preceding configuration and refer to it.
Example:
%dep.bt82.build.number%
Read this to get more information!