Archive for Mercurial

MacHg 0.9.10 released

I am happy to announce the release of MacHg 0.9.10!

MacHg 0.9.10 updates the underlying Mercurial version to 1.7.2 (The latest at this time.) MacHg 0.9.10 also includes various fixes for minor glitches (none of them too critical.) See the full release notes here.

Those people who downloaded the provisional 0.9.10 I released in this post should delete that version and get the official 0.9.10. (Although using the provisional 0.9.10 will not cause any problems whatsoever, it’s best to have everyone on the same page and there is one extra small bug fix to do with the cedit extension which is included in the official 0.9.10, as well the official MacHg 0.9.10 uses Mercurial 1.7.2 instead of Mercurial 1.7.1)

As always you can get the latest version from

http://jasonfharris.com/machg/downloads/downloads.html

Leave a Comment

MacHg 0.9.10 pre-released

Hi All,

Several people have now all stumbled upon the following problem: Mercurial 1.7 was updated and it includes a change where the repositories it creates by default are not backward compatible with earlier versions. Now that 1.7.1 has been out for a bit people are updating to the latest command line version of Mercurial. Now normally it’s perfectly fine to have an older version of Mercurial in MacHg. Normally I upgrade the version in MacHg in a staggered fashion due to bug testing and stability. (Also since it’s a Front end to Mercurial it doesn’t matter if a new feature is added to Mercurial proper since if an interface isn’t coded into MacHg then the feature is not used.) For a couple of weeks now the version I have used internally in my development has been 1.7.1. Thus due to this problem with version mismatch I am issuing a pre release of version MacHg 0.9.10 for those people who need it:

http://jasonfharris.com/machg/downloads/assets/MacHg0.9.10.zip

I would do this as a full release but unfortunately I am not in my home city in front of my home computer, thus the keys I use for Sparkle are not present on my machine. As soon as I get in front of my home machine I will issue an update that goes through sparkle. For now though use the link above. (Incidentally there are several non-critical fixes in 0.9.10 which you can peruse on the official bit bucket site.)

(Note, just in case you were wondering, trying to use MacHg 0.9.9 on a repository created by Mercurial 1.7+ will not in any way damage the repository, but it won’t work. To make it work use MacHg 0.9.10 above…)

Update: I have now officially released MacHg 0.9.10. So the pre-release version has been removed and replaced by the official version.

Cheers,

Jason

Comments (1)

MacHg 0.9.9 released!

I am really happy to announce MacHg 0.9.9.

Its getting really close to MacHg 1.0.0! Here is the release notes for MacHg 0.9.9

  • Major revamp of the Commit Sheet.
  • Files can now be excluded / re-included from the commit sheet, and visually disabled / enabled.
  • An expandable “Advanced Options” section is now accessible on the commit sheet. One can override the user or the date of a commit.
  • Introduce the “Amend Option”. Although Mercurial does not have a native command for this, MacHg uses Mercurial queues to do the amending of files. (this is the same as the git command.)
  • Fix a problem where if you click too quickly on a repository you get kicked back to the welcome screen instead of loading the repository.
  • Big internal enhancement to DisclosureBoxController so it shuffles views around better.
  • Add tooltip stating that the password will be stored securely in the system keychain.
  • Improve performance and avoid threading issues, by internally putting many events inside a delayEventsUntilFinishBlock.
  • Fix issue #110, where the times of commits would appear incorrectly offset by the local time zone.
  • Fix issues to do with date parsing. Ensures one gets the correct date when importing patches.
  • Make the rollback menu item disabled when there is no rollback information available.
  • Make sure the push / pull / incoming / outgoing counts are laid out correctly when resizing the corresponding sheet.
  • Fix issue #86. Previously, a collapse of multiple changesets would result in the historyView’s selected indices ‘sticking’ despite the collapse. Now, after a collapse, the ‘lower’ revision is selected.
  • Make the delete key in the ImportPatches sheet delete a patch from the list of patches we are about to import.
  • Fix for issue #126. Save the overall window size for non-independent window sizes.
  • Fix issue #96 : “Built-in” typo in the Preferences pane.
  • Remove unused “count”-string in PullSheet.
  • Fix issue #121. Corrected the documentation to use “Add Server” instead of “Bookmark Server”.
  • Fix issue #106. Generate a better name in the rename sheet and fix button layout.
  • Include nice addition from Eugene Golushkov to make parent revisions appear as buttons.
  • Also from Eugene Golushkov make the NSTextAttachments copy to the clipboard correctly.
  • Fix issue #114. Add a preference item to control if the views have independent window sizes. (Several people had previously asked for this option.)
  • Fix issue #113. Added a rebase option to pull sheet.
  • Fix issue #116 and #108. We can now ignore files with a ‘#’,’+’, or ‘*’ in them.
  • Fix pinning of the “Browse…” button in the local repository sheet.
  • Added some underlying support for undo /redo. The backup works perfectly, unfortunately it’s just too slow for large repositories like OpenOffice, so I will have to go with some plan B (but leave the functionality in for now…)
  • Add some documentation on the Help Generation process.
  • Add help topic about empty repositories. (Relates to issue #134).
  • Make building instructions for MacHg a little more prominent.
  • Document the simple instructions necessary to change the Mercurial binary used by MacHg in MacHg/CodeOverview.txt
  • Use only MacHg’s local Mercurial version and remove the preference item UseWhichMercurialBinary. It really makes no sense to allow the specification of a different Mercurial binary and it can only lead to problems. If the user wants to change the Mercurial version inside the MacHg bundle they can easily follow the documented instructions.
  • Simplify the include paths presented to the users in the advanced options. Previously it was a bit more general but users were getting confused. Thus Remove preference IncludeMacHgHgrcInHGRCPATH and always have the ~/Application Support/MacHg/hgrc file included in the HGRC path.
  • Make sure that the application support hgrc file contains a valid user name, so if the preferences are switched mid session then things still function correctly.
  • By default now include the users ~/.hgrc file in the HGRCPATH.
  • Make switching on the editing extensions in checkConfigFileForEditingExtensions check only in the ~/Application Support/MacHg/hgrc configuration file.
  • Fix issue #95. Check for the existence of a ~/.hgignore file on startup. If this file doesn’t exist then create it with the contents of DefaultFiles/hgignore.
  • Prevent #124 from happening.
  • Release version 0.9.9
  • Patch contributors for this release (Thank you all!): Eugene Golushkov, Sven Weidauer, Tojek Anselm, Marko Kaning

General status comment on MacHg: I am still working on the graph jiggling issue before I can finally go 1.0.0. (http://bitbucket.org/jfh/machg/issue/31) It is my top priority but its quite hard to do since getting incremental child information is an n^2 thing. I have stuff working in my own private branch, and I will hopefully finish the polish on it and release it soon.

Comments (2)

My Mercurial Prompt

This has come up a few times and so I thought I would post this. I use Steve Losh’s hg-prompt extension and I have it configured so that it displays the revision and the patch number if I am using Mercurial queues: Like so:

My Mercurial Prompt

To get this paste the following into your .bashrc file:

############################################################################# # Set up Prompt ############################################################################# noColor='\[\033[0m\]' blackColor='\[\033[0;30m\]' redColor='\[\033[0;31m\]' greenColor='\[\033[0;32m\]' yellowColor='\[\033[0;33m\]' blueColor='\[\033[0;34m\]' purpleColor='\[\033[0;35m\]' cyanColor='\[\033[0;36m\]' greyColor='\[\033[0;37m\]' boldGrayColor='\[\033[1;30m\]' boldRedColor='\[\033[1;31m\]' boldGreenColor='\[\033[1;32m\]' boldYellowColor='\[\033[1;33m\]' boldBlueColor='\[\033[1;34m\]' boldPurpleColor='\[\033[1;35m\]' boldCyanColor='\[\033[1;36m\]' boldWhiteColor='\[\033[1;37m\]' # Change the prompt to be user@host:path$ with some colors # simple version would be say # export PS1="${noColor}[${yelloColor}\h${noColor}:${greenColor}\w${noColor}] \$ " # Function that returns the last n path components of the specified path after # replacing $HOME with ~. Call like: # pathComponents path n nameColor seperatorColor function pathComponents { echo `python -c\ "import string,re; pth=re.sub('^$HOME','~',r\"$1\",1); n = string.atoi(r\"$2\"); nc=r\"$3\"; sc=r\"$4\";\ print nc + string.join(pth.split('/')[-n:], sc + '/' + nc);"` } # this is my mercurial prompt. It relies on the hg-prompt extension : http://stevelosh.com/projects/hg-prompt/ # its basically: basename rev(tip) on branch at bookmark patchnum#/patchcount# hg_ps1() { # hg prompt "{ on ${greenColor}{branch}${noColor}}{ at {bookmark}}" 2> /dev/null hg prompt "${cyanColor}{root|basename}${noColor}\ { ${blueColor}{rev}${greyColor}}\ {(${cyanColor}{tip}${greyColor})${noColor}}\ { ${greyColor}on:${cyanColor}{branch|quiet}${noColor}}\ { ${greyColor}at:${noColor}{bookmark}${noColor}}\ { ${greyColor}mq:${purpleColor}{patch|applied|quiet}${noColor}}{/${purpleColor}{patch|count|quiet}${noColor}} " 2> /dev/null } #export PS1='\u at \h in \w$(hg_ps1)\n$ ' function myPromptCommand { local newPWD=`pathComponents "\${PWD}" 4 \${blueColor} \${redColor}` # the trimed colored path echo -ne "\033]0;${HOSTNAME%%.*}:${PWD/$HOME/~}\007" # this sets the title export PS1="${noColor}[${greenColor}\h${noColor}:${newPWD}${noColor}] $(hg_ps1)⌘ " } PROMPT_COMMAND=myPromptCommand # Change the title of each window, and PS1 to reflect where we are

Leave a Comment

Versioning your application with the Mercurial changeset hash

A user of MacHg (Marko Käning) wanted to be able to see the changeset hash in the About MacHg box (see here). I had been meaning to do this at some stage and, well, given the request, now seemed as good a time as any… It turns out it was quite easy to configure XCode to create the appropriate information while building MacHg.

(In my workflow I release versions of MacHg every so often, and I want users who get the source code off of bitbucket and build it for themselves to be able to easily tell me something like “In such and such a version of MacHg I am seeing XYZ happen.”)

So now MacHg shows the following sort of thing when you look in the About MacHg box (note the grayed c0d2f1df774d hash code):

ok so how did I go about making this work? It happens in two steps:

  1. As part of the build process, get the hash key automatically and insert it into the applications info.plist.
  2. Inside your application extract the stored value from the hash key and display it in the about box

Steps to Automatically set the BuildHashKey when building your Application

  1. Open your XCode project.
  2. Under targets select your application.
  3. Right click on the target and choose Add -> New Build Phase -> New Run Script Build Phase, as in:
  4. Change the shell to be /usr/bin/python instead of /bin/sh.
  5. Then in the script, copy and paste the following — I actually did this in bash first but decided to do it properly again in python so that I will be able to read it again in six months time if need be, python being that much more readable :

import os, subprocess, re, sys

targetBuildDir = os.getenv("TARGET_BUILD_DIR") getChangeset = subprocess.Popen('hg parent --template "{node|short}" --cwd ' + targetBuildDir, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)

if (getChangeset.stderr.read() != ""): print "Error in obtaining current changeset of the Mercurial repository" sys.exit(0) # if you want the build to fail here since the changeset is malformed change this to sys.exit(1)

changeset = getChangeset.stdout.read() if (not re.search("^[0-9a-f]{12}$", changeset)): print "Current changeset of the Mercurial repository is malformed" sys.exit(0) # if you want the build to fail here since the changeset is malformed change this to sys.exit(1)

infoPlist = os.path.join(targetBuildDir, "MacHg.app/Contents/Info.plist") if not os.path.exists(infoPlist): print "Cannot locate MacHg.app/Contents/Info.plist" sys.exit(1) # if you want the build to not fail here change this to sys.exit(0)

result = subprocess.Popen('/usr/libexec/PlistBuddy -c "Delete BuildHashKey" ' + infoPlist, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True) result = subprocess.Popen('/usr/libexec/PlistBuddy -c "Add BuildHashKey string '+ changeset + '" ' + infoPlist, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)

print "MacHg BuildHashKey set to " + changeset

Of course you need to change MacHg.app to the name of your application. Also you might need to specify the full path to hg (ie /usr/local/bin/hg) in the line:
getChangeset = subprocess.Popen('hg parent --template "{node|short}" --cwd ' + targetBuildDir, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
Also you might want to have the build fail if the changeset is not available, since currently the script above just keeps going.  (I want users who download and compile MacHg to not get lots of critical errors if things are not set up just right.)

Using the BuildHasKey in your Application

Then back in your application you can have a method which will get the hash key from the info.plist:

- (NSString) macHgBuildHashKeyString
{
    NSString key = [[NSBundle mainBundle] objectForInfoDictionaryKey: @"BuildHashKey"];
    return key ? key : @"";
}
Then it’s just a matter of styling it and viola, you have the ingredients for versioning your application with the Mercurial changeset hash key. Actually, after doing this I found out that over at Cocoa is My Girlfriend he had done something similar but in bash.

Leave a Comment