Quick SVN guide for Git users; SVN: The Git Way

This post was first published on Quick SVN guide for Git users; SVN: The Git Way.

Why would a Git user want to switch to SVN, you ask?

Well, sometimes you just don't have a choice. Imagine working on a project that has been maintained in SVN since a decade. "But migrating an SVN codebase to Git is not a big deal at all." But there is stuff like CI/CD integrations to worry about too. That isn't a really big deal either but sometimes people take "Don't fix what ain't break." a little too seriously.

Reasons aside, having a good Version Control System (Distributed VCS for that matter) concepts, I didn't want to go SVN guides from the scratch to start with. While there were plenty of resources on the web regarding SVN to Git migration, I couldn't' find a quick and concise guide that would help me work with an SVN repo right away. If you are like me, you will find this article helpful. The following steps show you how can work with SVN the Git way.

Cloning a new repo

Checking out a repo is similar to how we do it in Git.

$ svn checkout <path-to-your-repo-branch> <path-to-checkout>

Example

The following checks out your code to your current working directory.

$ svn checkout https://mysvnrepo.com/myrepo/trunk .

Creating a new topic branch

In SVN, branches (and tags) are nothing but a simply a copy of one branch. A literal copy-paste of the files, unlike pointer to commits in Git. This fact took me a while to digest and get used to.

The following commands are SVN equivalent to git checkout -b branch.

$ svn copy <path-to-a-branch> <path-for-new-branch> -m "Message"

Example

$ svn copy --parents https://mysvnrepo.com/myrepo/trunk https://mysvnrepo.com/myrepo/branches/feature-branch
$ svn switch https://mysvnrepo.com/myrepo/branches/feature-branch

Working on the repo

Adding new files

To add new files, you would use:

$ svn add <path-to-file>

As for modified files, we don't need to add them. We can straight away commit.

$ svn commit -m "Commit message"

To commit only specific files, we need to list files after the commit message.

$ svn commit -m "Commit message" <path-to-file-1> <path-to-file-2>

If we want to commit a single file, we can do the following too.

$ svn commit <path-to-file> -m "Commit message"

Checking out new changes

The following is the SVN equivalent to git fetch && git merge or git pull.

$ svn update

Merging your feature branch to trunk

Merging a branch in SVN is similar to how we do it in Git.

$ svn merge <path-to-branch>

Example

$ svn update
$ svn switch https://mysvnrepo.com/myrepo/trunk
$ svn update
$ svn merge https://mysvnrepo.com/myrepo/branches/feature-branch
$ svn commit -m "Merge feature branch to trunk"

Deleting feature branch after merging

To delete a feature branch (or any branch for that matter), svn delete is used.

Example

$ svn delete https://mysvnrepo.com/myrepo/branches/feature-branch -m "Delete feature branch after merging"

Comments

[Idan Arye]

In my previous job I had to work with an SVN repository. So I just used git-svn - I kept a local Git repository and used git svn dcommit and git svn rebase to sync it with the company's SVN repository.

[tux0r]

Also, SVN has notably less overhead than Git and its command set is not that confusing. For many people, Git is just too much.

Thank you for your article!

[Dilip Raj Baral]

Thank you for your comment.

What overhead are we talking about? If we are talking space, Git takes up much less.
Ref: git.wiki.kernel.org/index.php/GitS...

Personally, I would say SVN reliance on remote server too much. Being able to create a repository and committing offline is one of the best features of Git.

Also, Git commands aren't really that confusing. It might just take a while if you are switching from SVN though because of the difference in concepts. If you are starting with Git (like I did), I don't think it's confusing at all.

[tux0r]

I actually started with CVS, slowly adapted SVN and I found myself in the VCS wars only a little later. I had to work with Git at my previous workplace, I killed my code more often than not thanks to Git's weird branching...

To each their own, I guess.

[Dilip Raj Baral]

Yeah. Branching concepts are bit different. In Git, a branch simply means a pointer to a commit while in SVN it means a copy (shallow) of a trunk (with ancestry information).

I had to use SVN about a year ago on a project and I was not a fan of how commits were lost while merging into another branch.

(I recently convinced the project to be moved to Git, though. :P)