Local vs remote mode of SubGit
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.
Local mode means that SubGit works on the same server SVN does. More to that, SubGit installs itself inside the SVN folder and SubGit files are quite integrated in the SVN system. Configuration file lives at the following path:
To configure SubGit in the local mode run that command on a local SVN server by the name of ‘www-data’ user (that is, if Apache is being used):
$ [sudo -u www-data] subgit configure path/to/svn/repository
With the local mode there is local SVN repository and that means that SubGit controls Git hooks and SVN hooks. Daemon controlling synchronization is not staying idle and is launched by SVN hook, that lets the daemon know when there are new revisions committed. In the conf file it’s being regulated by following option:
[daemon] idleTimeout = 0|N|infinity
In the local mode it’s ‘0’ by default that means the it exits immediately when idle.
When somebody commits to Git in the local mode, translation’s being made instantly because in general SVN and Git are always in touch and local SVN immediately knows if there’s any problem with applying those changes. Whereas commits to SVN are being made only after they were translated to Git.
In the local mode SVN works on behalf of a special system user that could have name “svn” if svnserve is being used or ‘www-data’ if it’s Apache. And Git in the local mode also works as a special system user, the different one. And when using local mode one has to configure them accordingly to each other because by the default those users can’t read each other’s files and for the synchronization they have to have a common access to some of those files. To learn more about it, check out our documentation. In the remote mode there’s no such a problem because SubGit only acts on behalf of the same system user as Git server software, usually it’s named “git”.
Remote mode means that SubGit could work from anywhere and communicates with SVN and Git using not only ‘file://’ protocol but also others like ‘ssh://’ or ‘https://’ protocol. Remote mode is much more popular and is being used by 99% percent of SubGit users. In general it’s preferable because it’s safer for a SVN repository, it allows to work with it not directly but through Apache or svnserve. Configuration file lives at the following path:
To install SubGit in the remote mode run the following:
$ subgit configure --svn-url http://svn.svnkit.com/repos/sqljet sqljet.git
In the remote mode daemon controlling synchronization is always on in the background. You could though run SubGit without a daemon using cron or post-commit hook. In the config file that is the following option:
[daemon] idleTimeout = 0|N|infinity
The value of this option is ‘infinity’ by default which means that when in idle daemon doesn’t exit but awaits in the background. Daemon checks for changes in SVN once a minute, that behaviour also could be changed in the config file, the option is:
[svn] ... # check for new revisions every 60 seconds fetchInterval = 60
For more details on that matter please look here.
When somebody pushes to Git in the remote mode, push is not being made right away, because at first SubGit translates those changes to remote SVN server to make sure everything’s alright. When somebody commits to SVN, translation also could be delayed because daemon checks for new revisions once a minute. That could be worked around using fake push command from any (fake) working tree:
$ git push GIT_URL :refs/heads/non-existing-branch
After running this command if branch doesn’t exist nothing will happen apart from that SubGit hooks will be called and SubGit hooks will trigger a synchronization process. If there’s an access to the SVN repository this command could be ran from the post-commit hook.
Now let’s move on to pros and cons of both attitudes.
Advantages of local mode and disadvantages of remote mode
In the local mode push to Git is being made instantly whereas in the remote mode one has to wait until SubGit makes sure the translation to SVN has been made successfully. Though commits to SVN in the local mode are being made only after SubGit makes sure that translation to Git was made successfully)
Local mode can work with one SVN repository and several Git repositories, in the remote mode one has to make separate installation for each Git repository. Usually it doesn’t create any problem, but if user has memory limitations, it’s probably wise to use our special daemon created to minimise that effect. For more info please refer to this shared daemon article.
With the local mode SVN and Git are almost always synchronized, whereas remote mode synchronization is being run periodically. When somebody pushes to SVN in local mode SubGit knows that automatically because there are SVN hooks and in the remote mode SubGit runs sync once a minute
Advantages of remote mode and disadvantages of local mode
With remote mode it’s possible to use any accessible SVN server from anywhere
It’s safer in a sense that SVN server is not being at risk of being blocked or destroyed by some poor accident which is a possibility when SVN server is on a file level a not-separable part of SubGit
It’s possible to use path-based authentication, if any protocol except file:// is used
With remote mode there’s no such problem as a necessity of having two separate system users for Git and SVN and having them connected and having right permissions for their common files which they ought to use in order to synchronize two repositories
If there’s some problem with Git with remote mode it’s possible to delete a current SubGit installation with the Git repository and translate a new one, and in case of local mode to delete anything like that is much more tricky
In general we recommend our users to avoid using local SVN server and ‘file://’ protocol and to use remote mode. Though both modes use the same way of translating data, the remote mode is considered to be safer and more flexible.