The path to using the SCM-Manager

Familiar situation? Cluttered version management

Using a version management system has fortunately become a given for software developers these days. But this concept is also appreciated and used in other professions, whether it's the novelist who automatically captures his current standings every evening or the engineering firm that manages its technical data. Thanks to Git and Mercurial, version management is no longer a thing that is reserved for professional use with servers. It only takes a short command to set up a repository that is ready to grow. Sometimes, however, this is exactly the reason why situations arise that are no longer optimal and where it would be nice to change something. Maybe it is the twelfth Git repository on the Samba drive, which then requires a little more overview, or the different systems for Git, Mercurial and SVN, which would like to be brought under one hat. Or perhaps a move from a cloud-based environment that is actually dear to us to our own servers is in the offing. The goals of SCM-Manager have always been the support of Git, Mercurial and SVN, an easy installation and flexible extensibility, so that it is always worthwhile to include SCM-Manager in the considerations. Be it operation on the home NAS or in the cloud in interaction with Nexus, Jenkins and other services. In order to simplify the first steps somewhat, we would like to describe here a few scenarios of how SCM-Manager can support a switch.

Scenario 1: From Network Drive to SCM-Manager

When you start small, it often starts with a simple directory that is put under version control. With Git and Mercurial this happens directly in the working directory, with SVN a second folder is sufficient. Possibly a folder moves to a network drive, because further accesses become necessary. And at the latest when the requirement for different permissions comes up, the provision of a server should be considered. The SCM-Manager works internally with the same directory structures that the native Git, Mercurial or SVN clients use. However, one should resist the temptation to simply copy the already existing directories to appropriate locations in the folder for SCM-Manager. Instead, an import or a normal "push" should always be used. For SVN, a dump created via svnadmin can be imported directly via the import function in the SCM-Manager ("Add repository" - "Import repository"). For Git and Mercurial, an empty repository can be created, into which the desired branches can then be imported via 'git push' or 'hg push'.

Scenario 2: Upgrade of an old SCM-Manager

In the second scenario, an older version of SCM-Manager is already running somewhere in version 1. Ideally, of course, this should be a 1.60, but what is ideal? And just between us: Even in version 1.60, this SCM-Manager is end-of-life and should be upgraded to the current version. So let's take the easy way first: Migrating the complete installation.

Complete migration from version 1

A prerequisite for migration to SCM-Manager v2 from an installation with version 1.x is that version 1.60 has been started at least once. This is the only way to ensure that all data is in the current format. After an obligatory backup (or even better on a test environment), an up-to-date SCM-Manager can now be started with the directory containing the data. This recognizes that there is a directory with v1 data and starts in the migration wizard. On this page, it is possible to select for each individual repository what it should be called in the new SCM-Manager or whether it should be transferred at all. Once this manual step is complete, the individual repositories as well as users, groups and other settings as well as permissions are converted and the SCM-Manager is started with the known data in the new look. It should be noted that any previously installed plugins will not be automatically reinstalled. So the first step should be a visit to the plugin page. Here a large amount of the plugins known from v1 are also available for v2. The existing data for the plugins from the previous installation will carry over after the installation, so no data should be lost here.

Import from a v1 instance

Since the SCM-Manager has been around for more than 10 years, it can happen that an installation has lost some of its structure and hence it is advisable to split it up into several new instances. If only the actual repositories and no metadata are to be transferred in this split, individual repositories can also be "pulled" from the old instance via import. Or there is already a new SCM-Manager v2 instance into which some repositories from an old installation are to be imported. Here the Script Plugin can be helpful. For this we have already published two scripts in the community forum, with which an import of several repositories can be carried out automatically.

The move to SCM Manager v2

A switch from one system to another needs to be well considered. This applies all the more if it is a part of a larger environment. Here it is a good idea to install the SCM-Manager on a test basis.

The test installation

To get a feel for how the SCM-Manager performs in the daily work environment, repositories can be mirrored using a plugin. A mirrored repository regularly loads all changes from another repository. In this way, the usual process can continue uninterrupted for an indefinite period of time, while the first experiments with productive data can be safely tried out on a sidetrack, so to speak.

For example, a Jenkins can be connected to a mirrored repository, which then starts builds accordingly for all changes in the productive system. The existing systems are not changed in the process, so there is no risk and ample time to test. Incidentally, it is also possible to set filters for a mirrored repository. For example, only certain branches can be included or commits without a signature can be rejected. The following figure shows the dialog for creating a mirrored repository in SCM-Manager v2:

The switch to the new version

Once the decision has been made in favor of the SCM-Manager, repositories from third-party systems can be imported very easily. If a repository has already been mirrored, it can be converted into a "real" repository by clicking on "Unmirror repository" in the repository settings under "Mirroring". Otherwise, existing repositories from third-party systems can also be imported directly without any problems. In the case of Git, LFS files are also imported directly. It is sufficient to specify the URL and, if necessary, user name and password, and the repository can be used directly.

Speaking of moving: Of course, the SCM-Manager also supports moves from one SCM-Manager to another. Repositories can be exported. Such an export can either include only the native repository data (i.e. the pure Git, Mercurial or SVN part) or additionally all metadata (i.e. all settings and other data such as pull requests from the review plugin). If a bit more security is needed, the exports can additionally be password protected.

When importing into a new SCM-Manager instance, it is only important to ensure that it is not older (i.e. does not have a lower version number) and that the plug-ins are up to date.

Conclusion

Due to its open structure, the SCM-Manager offers a wide range of possibilities. These are not limited in the interaction with other systems such as Jenkins, but are already evident in the import and export of repositories. In this way, an SCM-Manager can be flexibly evaluated, adapted and extended. Various options are available for transferring data from external systems as well as moving between SCM-Manager instances. We would be pleased to hear your story about the SCM-Manager. Do not hesitate to contact us if you have any questions or further requests.