For a large number of installations, it may be convenient to replicate our way of deployment in your company.
Advantages of this approach:
Disadvantages of this approach:
To provide the updates to your users, a central "repository" has to be set up (the term "repository" is completely unrelated to a Git repository). The repository must be accessible either over HTTP- or file-protocol and must provide endpoints for:
From now on, let's assume that the custom update server's URL is
updateserver may contain a port, too) and it offers following endpoints:
If you want to use
autoupdate file is the entry-point for the entire update procedure. It will be read by SmartGit on every invocation of the check for new version. For a reference
autoupdate file, refer to our main
autoupdate-file at http://www.syntevo.com/smartgit/autoupdate.
autoupdate file contains directions for each major version of SmartGit and its top-level structure looks like:
<updateinfo> <product id="syntevo.smartgit.release-X"> ... </product> <product id="syntevo.smartgit.release-Y"> ... </product> ... <updateinfo>
<product>-element will usually contain a
<version>-element which gives details on the update target version and has basically following structure:
<version> <major-version>...</major-version> <major-date>...</major-date> <build>...</build> <name>...</name> <date>...</date> <location>...</location> <update-url>...</update-url> ... </version>
You will usually want to copy these elements over from our main
autoupdate-file and only adjust the
<location>-element and the
<update-url>-element to your company-internal URLs. An example
<version>-element for SmartGit 17.1.2 with adjusted paths might look like:
The important URL is
<update-url> which specifies the URL-prefix for the update "control"-files. The
<location>-URL is of minor importance and will just be displayed by SmartGit if an automatic upgrade is not possible (which should almost never be the case).
Depending on the operating system, the URL-prefix will be completed to a full URL by appending:
osxfor Mac OS X
The complete URL for the Windows update control file will look like:
The "control" file specifies how the final SmartGit installation must look like after an update. The basic structure of a control file looks like:
HEADER build=... minRequiredBuild=... sourceRootUrl=... ... CONTENT ... <signature>
You will usually want to copy the control files from our website as is and only adjust the
sourceRoolUrl to your company-internal URL. An example Windows update control file for SmartGit 17.1.2 with adjusted URL might look like:
CONTENT section describes exactly how the installation should look like and consists one line for very file which will be present in the installation:
<sha> <type> <name-on-server> <relative-path-in-installation>
URLs for all files mentioned in the
CONTENT section will be composed by concatenating the
sourceUrl + / + <name-on-server> + . + <sha>.
The complete URL for
buildspecifies the SmartGit build number. It must match the
<build>-element and the hard-coded build number in the SmartGit binaries. Hence, do never change this field.
minRequiredBuildspecifies the minimum build number which the local installation must be of for a light-weight update (see Installation and Files). If the local build number is lower, an installation update will occur. Usually you will simply copy over
controlfiles as we have published them and only adjust the
sourceRootUrl. In case you want to change the installation directory (see below) as part of the update, you have to set
minRequiredBuildto the same value as
majorVersionNamewill only be used in the UI and should not be changed.
majorDatewill be used to decide whether an upgrade to a new major version is supported by the license and should not be changed.
executable64bitspecifies the binaries which will be launched after an installation update. Usually they should not be changed.
sourceRootUrlhas been discussed already and must always be adjusted.
copyPatternswill be applied to all files in the old installation which were not known to be part of the old installation ("unknown files"), i.e. such files are not listed in the
control-file of the old installation. Those unknown files which are matched by the pattern will be copied over to the new installation. For example,
bin/smartgit.vmoptionsis not part of the installation and hence will be copied over from old to new installation.
skipPatternswill also be applied to unknown files and directs SmartGit to ignore them when cleaning up the old installation. With regards to the cleanup, an unknown file may have been copied to the new installation, may have been skipped or may have not been handled in which case it will remain in the old installation. If the old installation is not empty after the cleanup, the SmartGit updater will warn about this fact and an
-archivedirectory with the unhandled files will remain on disk.
control-files can easily be fetched from our website. To fetch all files listed in the
control file, you have two options:
Help|Check for New Versionand copy files over from SmartGit's local update "repository" (see Installation and Files) to your update server.
The following system properties should be added to
The URL of the
autoupdate file which SmartGit will access can be configured by system property
control file ends with a
<signature> which secures this file against tampering. By default, SmartGit will reject
control files for which the signature does not match. To make SmartGit accept such
control files, you have to set system property
smartgit.autoupdate.checkSignature=false. Be careful! By switching off this important check, everyone who gains control over the update server can deploy arbitrarily modified and possibly harmful SmartGit binaries.
By default, the update check will be performed on every SmartGit startup (if at least 23 hours have passed since the last check) and from then on all 23 hours. You may optionally shorten this interval by adding system property
smartgit.updateCheck.force=true and specifying the desired interval in seconds using
When replicating the
control-files as they are and only adjusting the
sourceRootUrl, SmartGit updates from your company server will look exactly the same as when done from our main server. But as we have seen above, to use a custom update-server,
smartgit.vmoptions has to be adjusted and these changes must be preserved after an update. By default, SmartGit will copy "unknown" files from the old installation over to the new installation, so the file will be preserved automatically. However, it's better to not rely on this mechanism and instead make these system properties part of your custom installation. This way you will be able to add additional system properties on demand. In a similar way you may add, replace or remove additional files on demand, like the
Let's assume that our customized
SHA-1 of this file is FCF5C579466B184693A1305FD161008203F82CA1.
Let' assume we want to place following
SHA-1 of this file is 44737F607645106D5F52C097CE21E69025E8BDBB.
We will apply following modifications (highlighted in bold):
If updates are not working as expected, it can be helpful to debug the update mechanism by adding following system property temporarily to
smartgit.properties of your test installation:
After restarting SmartGit, you may grep