Using GIT, Subversion and Mercurial with PrimalScript
- Written by Alexander Riedel
- Last Updated: 22 April 2016
- Created: 11 December 2012
- Hits: 1396
For quite some time we have been asked to add support for the aforementioned version control systems to PrimalScript. But every time we looked into it, the API changed or the preferred system du jour changed. We didn’t want to add support for too many API’s that get potentially outdated fast.
But most importantly, many folks we asked indicated that they use more than one system. GIT for their own files, Mercurial for customer A and Subversion for customer B.
Even worse, some clients seem to insist that some homegrown system is used that either has no API or is simply to small for us to support. To make a long story short, all these systems have one thing in common: command line tools. So we decided to focus on that.
While PrimalScript had a customizable Tools browser for some time, it lacked the context sensitivity that this feature needs and many users switch side bars off completely. Projects would only work for a small subset of our users, since most scripts are a single file affair. Users writing PowerShell modules, which require multiple files, also rarely use projects. So we added a customizable tool button to the home ribbon, which primarily uses the folder location of a file for context.
You can add a global set of commands to this button by creating a simple INF file in PrimalScript’s application data folder:
Under Windows 7 that file is C:\ProgramData\SAPIEN\PrimalScript [YEAR]\CustomMenu.inf
We are using Git in this example, but really any command line tool will work. Just think of any command line tools you can write in Powershell and package with PrimalScript’s script packager.
Once that file is in place (restart PrimalScript, that menu is cached) a push on that button shows the commands:
Now, let’s assume that for the files in ‘My Documents\SAPIEN\Scripts’ you need some additional functionality. For example a way to replicate a Git repository to a remote location. So we add another ‘CustomMenu.inf’ file to that folder:
Once you open a file in that folder and click on the custom tools button you see the global custom commands as well as the ones local to that folder:
That way you can have Git replicate to a different remote location for any given folder, use Git in one folder and Mercurial for files in another. You can write up an ftp command line to push your web files to different sites in any given folder or simply use xcopy to copy your files to a server.
The output of these tools is simply displayed in the output window, so any potential errors or success messages show up there.
The following macros can be used in command lines and will be replaced accordingly before a tool is executed:
$ProjectFolder$ : The folder the currently open project resides in, if any project is open.
$WorkSpace$ : The full path of the current workspace file if one is open.
$Target$ : The target file, if any, of the currently active project
$TargetFolder$ : The target location of the currently active project, if one is defined.
$PowerShell$ : The PowerShell version number currently selected in PrimalScript’s ribbon (2 or 3)
$Platform$ : The current platform selected in PrimalScript’s platform selector (32 or 64)
$WinDir$ : The location of the Windows directory for the PrimalScripts’s process.
$WinSystem$ : The location of the Windows System folder for PrimalScript’s process.
$Selection$ : The content of the current selection in the active file, if any. (Warning: may contain carriage return/ linefeed)
$File$ : The full path of the currently active file, if any.
$FileName$ : The file name of the active document without path information.
$FileTitle$ : The file title of the active document. the title is defined as a file’s name without path or extension.
$FileDir$ : The folder location of the currently active document.
$Dir$ : The current directory of PrimalScript’s process.
$Line$ : The current line number in the active file.
$Col$ : The current column in the active file.
We are hoping that this will enable you to use any of the above mentioned systems more easily with PrimalScript and opens up some other integration possibilities in your local infrastructure.
This article applies to PrimalScript v6.5.136 or later.