Some time ago when starting a new project, it was decided to try using Git instead of Subversion. After a while, the team was divided into those who love Git (programmers) and those who hate it (designers and artists). The experiment on replacing Subversion with Git failed and on the horizon the prospect of the return of Subversion loomed.

Having scratched their turnips and shuddering at the memories associated with Subversion, the men decided: “Well, we are programmers!” And washed down their Subversion with Git and cookies. This is how the git-as-svn project was born.

Now we can use both Git and Subversion with the same repository. Moreover, access via Subversion directly uses data from the Git repository, unlike, say, SubGit , where a separate repository is used for Subversion.

Why did you need another bike?

In fairness it should be noted that both camps were right in their own way. In favor of Git, you can say the following:

1. In Git, you can do a branch on a task and quietly commit intermediate results without the risk of breaking everything.
2. Git, compared to Subversion, is unrealistically fast.

Against git:

1. Higher entry threshold:
   • Git is objectively more complicated than Subversion;
   • TortoiseGit is not as convenient as TortoiseSvn;
   • many things need to be done through the console;
   • many more ways to shoot yourself a leg.
2. Git doesn't do well with Windows clients.
3. To work in Subversion-style (updated → worked → filled → worked → filled ...) you need a lot more gestures.
4. No separation of rights within the repository.
5. When a large number of people are constantly flooded, people start to beat their heads (someone has time to wedge between pull and push).

And most importantly: Git does not give any advantages and creates additional problems if the files do not lend themselves.
')
When it became clear that the experiment on replacing Subversion with Git failed, they began to look for a solution from the current situation. During the search were found:

• Subversion support on github .
  Can be purchased complete with GitHub Enterprise for hundreds of oil.
• Dumb SubGit project.
  SubGit tries to keep Git and Subversion repositories in synchronous state through hooks. This architectural solution looks very shaky, although it should be noted that the implementation seems to be working.
• A fiercely slowing down python implementation of the Subversion frontend for the Git repository.
  The most important thing in this project is its small volume. After that, the task of implementing the Subversion frontend for the Git repository began to seem simply insane, and not completely insane, as it was before. :)

What is it and how does it work

This project is an implementation of the Subversion frontend for the Git repository. It allows you to work with the repository with at least:

• console Subversion client;
• TortoiseSVN;
• SvnKit.

Currently supported:

• svn checkout, update, switch, diff
• svn commit (!)
• svn log
• svn cat, ls
• svn replay (svnsync)
• partial checkout
• sparse working copy (svn --depth / - set-depth)
• git submodules
• LDAP authentication

In terms of performance, the work is not just comparable, but in some places even surpasses the native Subversion server.

How does a commit work?

One of the most important parts of the system is saving changes. In general terms, the idea is as follows:

1. At the time of the svn commit command, the client sends its changes to the server. The server at the same time remembers them. At the same time, the first check for the relevance of customer data occurs.
2. The server takes the head of the branch and begins to form a new commit based on the data received from the client. At this point, there is another check for the relevance of customer data.
3. The integrity of svn properties is checked for the data to be uploaded.
4. The server is trying to push a new commit to the current branch of the same repository with the console Git client. Next on the result of the push:
   - if everything is good - we load the latest changes from git-commits and rejoice;
   - if not fast forward - load the latest changes from git-commits and go to step 2;
   - if the hooks are repulsed - we inform the client;
   - if another error - we inform the client.
   

Thus, due to the use of console Git in this operation, we avoid racing with filling directly through Git, and we get hooks as a nice bonus.

Where is the repository svn data stored?

To present the Subversion repository, you need a series of data that is either missing in Git (for example, data on where the file was copied from) or very expensive to obtain (for example, revision number when the file was last changed). In order not to do their calculation every run, they are cached in the refs / git-as-svn / * branches. The same cache allows you to not break the compliance of Git-commits Subversion-revisions due to force push operations. ;-)

Known issues and limitations

At the moment, you have to put up with the following restrictions:

1. Subversion cannot change svn properties;
2. File copy history is not saved.

Svn properties

The main problem with svn properties is that some properties must be maintained in a synchronous state between Git and Subversion. So that this data does not diverge, svn properties are generated based on the contents of files from the Git repository (for example, svn: ignore is generated based on .gitignore). At a commit, the stored properties are checked against the data of the repository. This imposes an important limitation: you need to correctly form svn: auto-props, otherwise, when adding files, the user will have to bring them to the form that the server expects.

The most evil property: svn: eol-style. The main trouble is that the default behavior of Git in the context of eols is broken and corresponds to the .gitattributes file with the contents:

 * text = auto eol = native 

That is, with the default settings, Git changes the contents of text files.

After much suffering, a solution was found for the eol problem: you need to add a .gitattributes file to the root of the Git repository, starting with the line:

 * -text

This will require Git not to touch the end of lines on files until it is explicitly asked for it.

And what is the result?

At the moment, the project is in a leisurely design and is operated by one of the teams Mail.Ru Group. As a result, people are free to use an appropriate tool for their needs: designers use TortoiseSvn and upload changes directly to the master, and programmers use Git and live in their cozy branches. The whole environment became healthier, and colleagues stopped clenching their fists when someone next to utters the words Git or Subversion.

What should I do to poke a project with a wand?

To run git-as-svn you need:

1. Install Java 8.
2. Download the latest build from github.com/bozaro/git-as-svn/releases/latest .
3. Unpack the archive.
4. Start the server.
   

     java -jar git-as-svn.jar - config config.example - show-config 

As a result, a Git repository with one test commit will be created, accessible by the URL svn: // localhost / example / from under the test user with the password test. As a client, it is highly recommended to use a client for Subversion 1.8+.