OL Connect 2022.2 Sneak peek: versioning and collaborative work

OL Learn Blog Data

Get a glimpse at how version 2022.2 extends OL Connect’s versioning feature and allows you to collaborate with colleagues on common projects through online repositories like Github, Bitbucket and Azure DevOps.

What’s an online repository?

Just as its name implies, an online repository is a service that allows you to store files on the cloud, making them available to you – and to other members of your team, if you so decide – from anywhere. That means you can work from your office computer and from your home PC without having to copy files from one to the other. Your colleagues can also have access to the very latest versions of the files, without having to exchange them via email or through some shared network drive back at the office.

More importantly, the online repository maintains all the versioning information for each of your files, which allows you to examine or revert any change that was made to them.

There are many types of online repositories, and OL Connect 2022.2 supports the three major Git-based services in that space: Github, Bitbucket and Azure DevOps. Others may also be supported, but they haven’t been tested. Still, if they are Git-based, they should work the same way.

You may already have a personal account on one of those services (most of them offer some form of basic, free version), or your organization may have a corporate account. Either way, OL Connect 2022.2 will be able to work with them.

Getting started

The first thing you need, obviously, is an account with an online repository. In this article, we’ll be using Github for our examples, but the other Git-based repositories work in a similar fashion.

Once we’ve logged on to our account, our home page is displayed. From there, we’ll create a new repository that will host the files for a new project. We will need a unique name to identify the repository:

This image has an empty alt attribute

We’re making that repository private, so we can pick later which of our colleagues are allowed access to the files. Once the new repository has been created, we are presented with a URL that OL Connect will use to access the files for that specific repository. We’ll be needing that URL in a minute, but for now, we first have to go into our profile Settings to obtain a personal token that will allow OL Connect to access all the files in our name. This personal token is called an app password in Bitbucket, or a personal access token in DevOps, but they’re all exactly the same thing: OL Connect will use them as the password to our account when it needs to read/write information in the repository. That step is only needed once.

The token can control which operations are allowed, so we get presented with a list of options. For now, let’s just allow everything because we want to make sure OL Connect will be able to perform all tasks as needed. Let’s give a name to our token: OL Connect and then click the Generate… button.

We’re presented with a token, which will look something like this:


Make sure to copy that token somewhere, because you won’t be able to see it again!

Finally, we need to put some content in our online repository. We’ll just add a data mapping config we have lying around, any will do. We use the uploading an existing file option in Github’s <> Code section to do that. The page asks us to commit the changes, we’ll just set our commit comment to Initial upload:

This image has an empty alt attribute

Setting up OL Connect

In OL Connect, we now need to tell the application (just once!) how to access this online repository.

In the Designer, we go to Window > Preferences > Versioning and fill out the fields with the proper information. The Password field for the Remote repository section is where we paste that token we created earlier:

This image has an empty alt attribute

That’s it, we can now start accessing our project from OL Connect.

Cloning the repository

Our first step is to create a local clone of the online project. This will let OL Connect know where the local version of the online repository is stored so it can publish any changes we make locally to the remote location. We go to Project > Clone…, and that’s where we paste that URL we were presented with in Github when we created the repository:

This image has an empty alt attribute

By default, the local repository is created with the same name as the online repo, as a subfolder to the local <userhome>\Documents\OL Connect folder.

That’s it: your local and remote repositories are now in sync!

Publishing changes online

Now that we have a project, we can make changes to it. We’ll just change something (anything, really!) in our data mapping configuration, just so we can commit the change locally. Notice how, after this latest commit, the display in the Versioning history panel shows that only one side of the commit has been performed:

This image has an empty alt attribute

The Initial upload displays a full circle, meaning the local and remote versions of that commit are in sync. But the latest one only shows half a circle on the left hand side of the axis, indicating the commit was made locally but has yet to be published. If someone were to make changes to the online version that the local version doesn’t have, then that half circle would be on the right hand side of the axis.

So let’s publish our changes to our online repository. This is done via the Publish Commits… option in the Project menu. A confirmation dialog is displayed, stating that the changes have been published. And now the Versioning history panel is updated to reflect that both the local and remote versions are in sync:

This image has an empty alt attribute

Using tags

Another new feature in OL Connect 2022.2 is the Tag functionality, which allows any commit to be identified with a user-defined label. Think of it as setting a flag on your versioning history whenever you want to highlight that, at that specific stage, something is more remarkable than on other commits. For instance, we can mark this latest commit with a tag named Version_1, thereby indicating that this is our first version of the entire project that goes into production.

To do that, we simply right-click on one of the commits and select Set Tag, then enter a tag name (spaces are not allowed):

This image has an empty alt attribute

The Versioning history panel immediately displays the change:

This image has an empty alt attribute

And of course, we can publish our new tag to the remote repository via the Project > Publish tags… option, to let our colleagues know that a new tag has been added to the project. You can add as many tags as you like, you can delete them or re-use them on a different commit (which is the equivalent of moving a tag). In short, they are a convenient way of marking the status of your project at any given moment. Don’t overdo it though: having too many tags is like having none: nothing in your versioning history would stand out!

Sample projects

There is one final change on the versioning front in OL Connect 2022.2: the sample projects now automatically create a versioned project in the …/documents/OL Connect folder. Unfortunately, due to time constraints, we could not yet tie that functionality to the online repository. So sample projects create locally-versioned projects that cannot easily be uploaded to an online repository. We will fix this in the next release of OL Connect, and we will also be publishing articles later on, explaining how such local projects can still be published online with a few manual steps.


Whether it’s because you work in collaboration with others on a project, or because you just want to make sure your projects are available from anywhere, or because you don’t want to bother having to back up your local hard drive, online repositories are a precious addition to OL Connect. You can immediately start moving existing projects to the online repository and start managing them from a central location.

This isn’t the end of the versioning project, though. We have plenty more ideas for the next versions (including the versioning of additional types of resources, like presets, workflow configs, NR flows, etc.), and we will add them based on the feedback we get from the current feature set. So feel free to make suggestions!

Tagged in: Bitbucket, Collaboration, Github, Versioning

Leave a Reply

Your email address will not be published. Required fields are marked *