What is the canonical way to update the TextMate2 bundles (in particular the built-in ones) ?
Related
I have a Mac "Shoebox" app that internally uses NSDocument objects, but does not expose the concept of individual documents to the user. (I rely on NSDocument to make syncing via iCloud easier.)
My problem is that when a version conflict arises, my app shows the default NSDocument conflict resolution alert (see below) letting the user pick one or two winners.
In the concept of my app this doesn't make sense. Is there a way to intercept/prevent that alert and handle the conflict programmatically?
I know that I can detect version conflicts with the code below. However, I still need to prevent the alert sheet.
[NSFileVersion unresolvedConflictVersionsOfItemAtURL:document.fileURL];
Example conflict resolution alert:
This is the built in behavior of NSDocument when it discovers there are unresolved version conflicts. If you do not wish to use it you'll have to drop support for NSDocument and use a lower level abstraction like NSFileManager + NSFileVersion.
You can override + (BOOL)usesUbiquitousStorage and return NO.
This will no longer show the ubiquity conflict panel.
See the doc Resolving Document Version Conflicts
Strategies for Resolving Document Version Conflicts
Your application can follow one of three strategies for resolving document-version conflicts:
Merge the changes from the conflicting versions.
Choose one of the
document versions based on some pertinent factor, such as the version
with the latest modification date.
Enable the user to view
conflicting versions of a document and select the one to use.
Which strategy is best to use depends a lot upon your document data. If you can merge the contents of different document versions without introducing contradictory elements, then follow that strategy. Or choose the document version with the latest modification date if your application doesn’t suffer any loss of data as a result.
Generally, you should try to resolve the conflict without involving the user, but for some applications that might not be possible. If an application takes the user-centered approach, it should discreetly inform the user about the version conflict and expose a button or other control that initiates the resolution procedure. An Example: Letting the User Pick the Version examines the code of an application that lets the user select the document version to use.
I already searched on the net a way to update the SQLITE3 version of Xcode, but I didn't found any working way. It is a way to do it?
If you want to use your own version of sqlite3, perhaps because you want to use newer features only provided by a later version, then probably the best thing to do would be to create an Xcode static library project to build sqlite3 and then include that library with your app (statically linked). This will avoid using the system version.
This should be fairly trivial, given the number of source files that make-up sqlite3.
You could probably make a dynamic library version, but that's slightly more complicated, though certainly possible.
I've just realized, that some of my TextMate bundles would probably profit from updating.
The problem is, that some of them are pre-packaged with TextMate under /Applications/TextMate.app/Contents/SharedSupport/Bundles and others are manually installed by me under ~/Library/Application Support/TextMate/Bundles.
Now the question is, if I for example wanted to update the Ruby on Rails bundle, which is under /Applications/TextMate.app/Contents/SharedSupport/Bundles/Ruby on Rails.tmbundle, should I just delete it, and manually download from github into the ~/Library folder?
Won't I break something if I delete preinstalled bundles and replace them with newest version from GitHub?
And second question, is there any simple way to tell TextMate to just load all of the newest versions of installed bundles?
I recommend using GetBundles, you can get it from the bundle SVN as described here - it's kind of a "package manager" for TM bundles, and will handle updating the builtin ones correctly too. (I also recommend the other two plugins from that blog post, but that's unrelated.)
My company is creating a cheaper version of our product that will only upgrade from an older version. To accomplish this, I would like to create an installation that will ONLY upgrade from a previous version. It will not install the full product.
Is there a straightforward way to do this? I have considered:
1) Creating a custom action that checks the registry for the old version first;
2) Creating a patch/hotfix installation
Is there a better method to do this? If not, are there any large pitfalls and drawbacks to these methods? Method #2 seems like the easier method, but this is a pretty big upgrade (though not a "major upgrade," from a technical standpoint). I don't like the appearance of a hotfix when the upgrade is no such thing.
By the way, I am writing the installer in WiX.
This really boils down to one question: does the upgrade move or remove files?
If it does, you need a major upgrade. In this case just make sure that your new version uses the same Upgrade Code as the old one. Windows Installer will take care of the old version removal.
To prevent the package from performing a standalone installation you can use an upgrade rule. You can define a rule which detects older versions and saves them in an installer property. This property can then be used as a launch condition.
If the upgrade doesn't need to remove files, you can use a patch. In this case you don't need to worry about standalone installations.
We have a software that has couple of executables inside. One of the executables is Windows service, and it doesn't change that often, usually we release many updates to the main executable, but the service version is same inside installer.
When service is installed first time or upgraded with newer version, we need to run custom action. We managed to solve first install part, but we don't know how to determine that version we're installing now is newer than one that already exists. Sort of if(newver > oldver) run custom action.
Thank you in advance
- Jack
You can try using the upgrade rules of your package. More details here: How to implement WiX installer upgrade?
Rob Mensching (the second answer in the linked thread) shows an example for upgrade rules. You should first familiarize yourself with the Upgrade table and how upgrade rules work. There isn't an easy answer or a quick fix for this in WiX.
Basically, you should have 2 upgrade rules
the first sets a property when an older version is found
the second sets another property when a newer version is found
After that you can use the older versions property to condition your custom action. For example, if the property is named OLDERVERSIONFOUND the custom action condition can be:
OLDERVERSIONFOUND
or something like
OLDERVERSIONFOUND > "1.0.0"
Your best bet is to store the "service" version somewhere in the registry, search for that registry value during upgrade and run your CA if newver > oldver (and the CA should also update said registry value to newver)
Note that Custom Actions are (generally) an admission of failure. I always try to separate out the configuration portion of setup to a pre-install (for sysadmins doing deployment) or post-install (for interactive installations) step - often a separate executable.
Declarative installations with no custom actions are much more reliable - if you can figure out how to rewrite the service so that your custom action is no longer required, you'll be much better off in the long term (this doesn't help when you're under pressure to release now, but it's something to think of for future releases)