release 1.6.10 of the PowerShell Provider for Mercurial

BitBucket project link: http://bitbucket.org/artvandalay/mercurialpsprovider/

Release 1.6.10 introduces two features. The first is a special case of getting the content (gc) of a changeset. When the changeset's path ends in ":stat" then the returned content is the three bottom totals from "hg di --stat", 1) number of files changed, 2) lines added, 3) lines removed. In my opinion, the task of obtaining those numbers for a changeset is probably frequent enough, and the hassle saved by delegating the parsing substantial enough, to justify placing direct support for it in the provider. It's possible that :stat will be joined by other path suffix "modifiers" in the future but only if the effect achieved is similarly frequent and substantial (i.e. no path modifiers for rare or trivially-achieved tasks).

The second feature is a module script file, MercurialProvider.psm1, which contains helper PowerShell functions for common needs. Currently all the functions are for more convenient usage of the ":stat" modifier.

release 1.6.9 of the PowerShell Provider for Mercurial

BitBucket project link: http://bitbucket.org/artvandalay/mercurialpsprovider/

The big user-visible change this time is the optional parameter -HgExtraParameters. In practice someone would probably use a shortened form like "-hgextra". This parameter is for additional hg parameters when the command returns something other than changesets and therefore -Filter doesn't apply. If you're getting a changeset's content, which is its diff against its first parent, you could include -hgextra "--reverse" after the path to instead see a diff that reverses the changeset.

Underneath, the changeset cache has also gotten smarter since 1.6.8. It now remembers the exact identifiers that have resulted in each changeset in the cache. This means that when a relatively strange identifier like "-1" yields a cache miss but a successful result from Mercurial, the same identifier will pull from the cache from then on. If Mercurial can figure out how to link a particular identifier with a particular changeset, then the cache will "learn" that.

The other minor performance enhancement is the addition of a one-entry "command" cache. The last hg command executed, and its result, is stored. When the same command would've run multiple times in a row, only to get the same output each time, now it will only need to run once for the sequence. Given the caching already present at the level of changesets and changeset manifests, the primary benefit to this command cache is speeding up when a command fails. When this happens, the Provider infrastructure appears to rerun the failed command five times. The command cache allows for the command to fail faster each time...