At TMate Software, we are devoted to making your life easier. Even though we don’t give all out our products for free, we’re trying to make our pricing and licensing system as flexible, transparent and cost-effective, as possible. An important part of it is the number of Git committers and the limits, related to it. Since version 3.3.4 we have introduced a more fair and useful system of counting them and dealing with exceedances.

Barcelona, Spain, September 3, 2018 - Atlassian announced today that TMate Software is a launch partner for Atlassian’s new Data Center approved apps. SVN Mirror for Bitbucket is now listed on the Atlassian Marketplace as a Data Center approved app.

In our previous post we explained, why there could be only one asterisk in a mapping path segment to prevent ambiguity. Since then we have received several requests for a workaround, and here it is! In SubGit version 3.2.6 and SVN Mirror Add-on version 3.3.9 multiple asterisks are allowed.

To define user’s repository layout SubGit uses branches mapping. Each directory (branch or tag) is mapped to a Git reference in the Git repository. The mapping can be one-to-one some certain branches/tags/trunk like

There are several aspects to it, when talking about SubGit license keys. Couple of conditions to meet to get a free license, couple of options for those who want an extended commercial license. In this article we will try to cover all the questions that could occur when thinking about SubGit licenses.

Today we’re going to answer the question that has been asked quite frequently:

If there are two remote repositories and there’s no filesystem level access to any of them two, besides other things it means that there’s no access for SubGit to their hooks. That means that those two repositories always accept commits, there’s no way to change that behaviour and to build in some consistency check.

SubGit has two forms of existence. It can work in remote mode and local mode. What mode is suitable for you? With 99% probability — remote mode. But tet’s look at first at the basics.

In this guide we will overview synchronization of Git and SVN repositories via SubGit.

Many questions arise when it comes to the topic what are shelves, how to use them and why could it be useful to do so at all. To lit some light on the question at first it’s needed to explain a bit the difference between branches in Git and branches in SVN. In SVN branch is represented by a directory and files inside that directory are commits. In Git there is no direct association between a commit and a branch. Commits in Git contain various information e.g. unique SHA1, author, time and date of creation, SHA1 of the parent commit, but do not contain the name of the branch in which they have been created. Therefore to translate commits from Git to SVN and to assign all commits to their branches SubGit uses a special algorithm that logically analyses all given data and makes usually a very wise conclusion about to where each commit belongs. But sometimes it is not quite obvious a decision as in some particular cases it’s not possible to determine one commit’s branch. And at that exact moment shelves come into the scene.

If you try to setup git-http-backend for Apache and see the message:

People who use Git on Windows often complain about “LF will be replaced by CRLF” warning an other problems related to line endings. While googling error messages one can see a lot of posts written in 2008-2010 years that recommend to set “core.autocrlf” config option to true or false.

Some of you may know that we are already working on the next version of our tool, SubGit 2.0. This new version enables bi-directional synchronization of Git and SVN repositories located on different hosts.

Usually we talk about creating a Git mirror of existing Subversion repository. However, SubGit makes no difference between two and it is equally easy to create Subversion mirror of a Git repository (or merely translate Git repository to Subversion). Here is how:

Recently we were given a task to create a readonly Git mirror of a Subversion repository. We’ve used SubGit and svnsync to accomplish this task, all went pretty smooth and I’ve decided to publish a small HOWTO on that topic.

We use our SubGit product for self-hosting for more than a year already, but until now we didn’t have Git side of repository open for the public. Today I’ve found some time to make necessary changes to the Apache configuration and, voilà, our dear users may now use Git to get SVNKit or SqlJet source code. Just run:

Finally, we’ve released SubGit 1.0!

Today I’d like to describe how to migrate from Svn to Git, minding existing infrastructure. One of the most common Subversion servers configurations is Linux server with Apache and mod_dav_svn module serving one or more Subversion repositories. Each Subversion repository may contain one or more projects. Of course, I will use SubGit to make migration smooth, i.e. without a need to force users to make a switch from Subversion to Git overnight.

I’d like to start this blog with a few real-world examples on how to set up SubGit assuming infrastructure that is already in place. This post will take place in a strange world of Windows.