This SmartGit preview version comes with more Log improvements and bug fixes.
One of our OS X users has reported SmartGit refreshing problems when running in a Windows 10 Parallels VM. SmartGit’s low-level Java timers are relying on a “consistent” system time (which will only be advancing). But, as it has turned out, due to clock synchronization issues, this may not be the case for such a setup:
Finally got to the bottom of this! Turns out to be a mismatch in the way that Parallels is emulating the real-time clock (RTC). When you install under bootcamp it sets this registry key to tell Windows that the RTC is in GMT:
Parallels is however incorrectly configured and is emulating the RTC in LOCAL time, not GMT! And for some reason, something in Windows keeps triggering it to correct itself to the RTC while the OS is booted (I can see that in the event logs). Not sure why it does that, but it happens quite regularly during the day. Since the RTC is not correct, it puts the system to LOCAL – 8 hours, (GMT – 16), and if I have the Parallels time sync service active it quickly notices and corrects it.
One way to work-around this problem is to disable the time sync service:
I have the Parallels time sync service off at the moment and have told Windows to expect the RTC to be in LOCAL time, and now it is all working nicely.
I have also been on calls with Parallels second level support who is talking to their engineers and they hopefully can make it work correctly in a patch release of Parallels, because if I boot my Mac into bootcamp natively right now the time will be off because Windows will think the RTC is LOCAL time, while in fact the Mac always has it set to GMT.
While eye trackers are not (yet) common computer peripherals, they have some fascinating potential to change the way we could be interacting with computers. I’ve done some experiments with the Tobii Eye Tracker 4C, a low-priced consumer device, to see whether/how it might improve SmartGit’s usability. The device is not pixel-precise, hence the interaction has to be restricted to larger areas of SmartGit’s user interface. The four screencasts below include the “gaze trace” and give some ideas of how eye tracking based interaction could look like:
Expanding/enlarging focused views, like the Journal
Adding details to focused (groups of) UI elements
Note that at least for my eyes, the precision was not sufficient to determine a single focused row in the tree, but only a bunch of 3-5 rows.
Scrolling the Commits graph by gazing to the top/bottom of the graph
Activating a (hidden) tab
For upcoming SmartSVN version 9, we are going to deprecate the OpenAPI. For the next major version (after release 9), the OpenAPI may be removed entirely. The functionality of all bundled plugins (e.g. the JIRA plugin) will be preserved.
Non-commercial users sometimes complain about warnings and final deactivation of older SmartGit versions. Now why are we doing this?
First of all, we’d love to see everybody running the latest version of SmartGit, regardless whether commercial or non-commercial user. We are steadily improving SmartGit and only supporting (fixing bugs in) the latest release version. Hence we are confident that the latest version contains the best features and is most stable.
Commercial users get between 1 and 3 years of updates. That means they can use any major new version which we release up to 3 years after the purchase date (including all bug-fix release, even if released later). If they want to use newer versions, they have to purchase update licenses.
Non-commercial users get SmartGit free of charge. The upgrade to a new major version is as easy as a download and will become even more convenient with upcoming versions. Hence, costs are only a few minutes of time vs. gain are new features and improvements in other areas.
Our gain of having non-commercial users running the latest version is a faster spreading of new versions, resulting in better reviews and less problem reports.
We are frequently getting bug reports of “normal” files showing up as a missing/unversioned file pairs on OS X. This happens if they contain non-ASCII characters (like German Umlauts) in their names and they have been added from another platform, like Windows or Linux or directly from the Repository Browser.
Known Subversion problem
This is a known problem of Subversion: in short, Subversion stores file names “as is”. When adding a file “
schÃ¶n” on Windows, its name is stored in this “composed” form in the repository. When checking out the file on OS X, the filename is converted to “decomposed” form when writing to the file system, resulting in “
svn status will see a different file in the working copy than in the repository and hence report the missing/unversioned file pair. Further details can be found at Subversion issue #2464 and in the Subversion Wiki.
Unfortunately, it’s currently not clear whether this problem will be solved for Subversion/when the fix will be present. The only known workaround is to get rid of such special characters in the repository completely:
- in case there are only a few files, you may use the Repository Browser to Rename the offending files, then update your working copy
- in case there are many files affected, it will be better to check out a fresh working copy on Windows or Linux, rename all offending files in the working copy and finally commit all these renames at once
One of our users has just shared a solution with us to invoke SmartGit’s Blame directly from within Visual Studio: in Tools|External Tools, SmartGit has to be configured as new tool with appropriate command line parameters:
Any title you want
Path to smartgit.exe
The configuration might finally look like:
With the tool configured as described, you will just invoke Tools|Git Blame when there’s a file open, and SmartGit will blame that file and scroll to the line which has the caret in Visual Studio.
SmartGit can be licensed for a monthly fee now, starting at USD 4.90 per month. This includes support and free (automatic) updates to the latest major version. The subscription can be canceled on a monthly basis:
From time to time we are asked whether SmartGit supports sparse checkout? The answer is: it does once configured. Let’s assume you have a remote repository with two top-level directories:
/ /dir1 /dir2
To have a sparse clone of only directory dir1, initialize a new local repository:
$ mkdir sparse $ cd sparse $ git init
Enable sparse checkouts in .git/config by:
git config core.sparsecheckout true
to .git/info/sparse-checkout, open the repository in SmartGit and use Remote > Add to add your remote repository and finally Fetch and Checkout.
If you already have an existing local repository which you want to make sparse, enable the git config option and configure .git/info/sparse-checkout as above and finally re-read the repository tree using:
git read-tree -m -u HEAD
Now SmartGit will only show dir1.