Co-Existence Subversion & Git

You are definitely not alone when you have a wide range of Subversion repositories, but want to move to Git.
Or you have a lot of users who want to use SVN, but also a lot of users wanna use Git instead.

Introduction

There are even more reasons to have more than one VCS:

• Migration, Git is more sophisticated than Svn and more reliable (more than one point of restore against one point of disaster).
• Co-existence, preparing the migration mau need both systems to work next to each other.
• Proof of Concept, before deciding to migrate you want to know if the solution works for you.
• Mixed, one or more of the above mentioned items.

Git is powerful, but has also a steep learning curve, making the implementation difficult.

The first very basic question is can you have 2 VCS systems next to each other?
The common answer is Yes, the more advanced answer is Maybe, and the smart answer is ...

Important remark

One of the possible solutions is using git svn. That solution is not mentioned, because I want to have a complete separated Git from Subversion.

Git vs SVN adaption

Of coarse the normally answer should be stick to just one VCS, but that is beyond the main question, in the end you want to have only one VCS, but:

• Many scripts are working with SVN
• Migration of all scripts may not be possible or not wanted at the moment.
• The Subversion-workflow is easy, embedded and well understood
• The adaption of Git is difficult due to the its steep learning curve.

Migration and coexistence

Migration can not be done without a intermediate state, meaning there will always be a period of coexistence of both the old and the new state.
Big bang migration is possible. The problem of coexistence is then minimized in the development phase.
But with a new workflow for the development the problem is not the coexistence but the adaption.
So in the end, you always have coexistence. Better accept that coexistence is part of the migration!

Knowing me, knowing you

No, not at all. Both systems should not know anything about each other, so:

Subject	Subversion	Git
Repository	Repository is stored into the directories .svn	Local repo is stored into the directory .git
Ignores	The embedded svnignore contains .git	File .gitignore contains .svn/

But things can be complicated. Most developers using tools to do the job, in the dev-tool/editor as add-on, standalone as separate tool or a command-line client. Examples:

Tools	Subversion	Git
CLI	svn	git
Standalone	Cornerstone	Sourcetree
Add-on	Sublime-Text, Eclipse	Sublime-Text, Eclipse

Add Git to Subversion

The first scenario is to add Git to an existing Subversion repository .

• Assuming the remote repository will be stored into GitLab
• Assuming the User of Gitlab is named 'HaFr1954'
• Assuming the subversion project is named 'AWK'
• Assuming the subversion project is located in '/Sources/AWK'.

The steps are:

• Goto the Website of GitLab and Login with the UID 'HaFr1954' (Replace the name by your name)
• Create a new blank project
  • Project Name: 'AWK'
  • Project URL: https://gitlab.com/HaFr1954
  • Project slug: awk
  • Project description: <Make your own description>

Problems

1. Weird Differences. After Git Commit & Push and the usage of Subversion Commit, some local checkouts have differences (git status).
2. Commit Sequence. Does the sequence of commit causing anomalies? It is not expected, but it can occur.

Weird Differences

After Git Commit & Push and the usage of Subversion Commit, some local checkouts have differences (git status) .
First try to find the difference:

$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
  modified:   myfile

# This difference does not show and difference
$ git diff master origin/master

# This might show a difference
$ git show HEAD:myfile|md5
$ md5 myfile

# To get rid of this problem do:
# 1. Removing the files from the index
$ git rm --cached -r .
rm '.gitignore'
...

# 2. Reset the indexes
$ git reset --hard

Commit Sequence

I have to admit, I always start with the Git Commit and Push before doing the Subversion commit. And I am getting anomalies.
The main problem is that why is not that easy to pinpoint. There are several reasons:

1. To Git-Commit & Push I am using Sourcetree, Git-CLI and a home-made-Bash-Script.
2. To Svn-Commit & Push I am using Cornerstone, Svn-CLI and a home-made-Bash-Script.
3. The Bash scripts are scheduled and run twice a day.

Things are getting complicated just by the statistical number of possible different occurrences (servers maybe down so there is no way to be sure which VCS action is taken first).

File Mode differences

The following problem may also occur after you are moving a folder to another location (MAMP update for instance).

Suddenly

$ git status

finds a lot of differences. Try

# Compare the differences and ignore whitespace and line endings.
$ git diff -w
diff --git a/.gitignore b/.gitignore
old mode 100644
new mode 100755
diff --git a/.htaccess b/.htaccess
old mode 100644
...

As you can see the differences are the file access (chmod) of the files. To eliminate these differences:

$ git config core.fileMode false

And now the differences are only real file differences.

A more solid solution is to use the gitattribute file, used to change settings for a single subdirectory. If you set core.autocrlf to false and still have line ending normalization problem, please search for .gitattributes files in every subdirectory of your repository, and verify if it has a line where autocrlf is turned on:

• text=auto

now you can turn off in all .gitattributes files you find in your repository

• text=off

See also

• Implements Blog, Using Git and Subversion together.
• Net Instructions, Git and Subversion together.
• Git-SCM, Git and Other Systems - Git and Subversion.
• Transition SVN to Git, A private wiki-page for the transition/migration of SVN-repo's to Git.