SVN vs Git source control

News & General Discussion
1

Have used SVN, with TortoiseSVN in windows, for years which has great UI, 1 step commit (because latest version only unlike git - simple but more limited?), great merge and diff tools come with Tortoise and it just seems a winner.

But being pushed towards Git and GitLab for more team-based work and I have yet to really see what is so good about it! Git seems to be focused on archaic (to me, who likes UIs and not learning syntax) console commands, though UIs are available. And checking out the whole history may be useful but does lead to more disk use & an extra step to push up a commit to the master.
Then you have LFS support to setup which SVN somehow handles itself, maybe not well?!

If you have used both then what are your views on SVN vs Git?

2

SVN? IMHO itā€˜s :sweat_smile::face_with_spiral_eyes::rage::eyes:

I came from a really decent/good VCS called Perforce to TortoiseSVN with only the Explorer right-click GUI and it was terrible. Especially handling merges was a catastrophe. Of course I didnā€˜t feel like learning a new VCS when there were better alternatives and since most in the team had quarrels with SVN we switched over to Perforce for the next project.

GIT itself wasnā€˜t easy to pick up either but at least the basics made sense and the community was incredible so there was a solution to any problem available. Iā€˜ve used Github Desktop (very basic) but prefer SourceTree since itā€˜s also free and handles submodules/subtrees and git flow and LFS. Itā€˜s a breeze. If I create a Unity project it automatically turns on LFS.

Having the whole history on your PC is a blessing too. Itā€˜s tremendously fast, and perfectly works offline. Disk space is cheap, like cheaper than Starbucks.

1 Like
3

Imo both are not suited to unity, the very best would be perforce which is built for things like this and free for first 5 users. If not possible then I personally would go with Git + LFS using a GUI on top for most things

I know there are users who prefer/like SVN, I think @Ryiah had some decent justifications for using it in another thread (sorry for pinging you if this wasnt you)

1 Like
4

Having worked with both, there are pros and cons which really depend on your team members.

SVNā€™s simplicity can be a double edged sword. Itā€™s great for artists and other non-technical team members because it reduces the opportunity for screwing things up. Itā€™s issue come up if you want to use branches, as they can get very complicated to properly manage and merge. It works best if you stick to trunk-based development.

Git can be a headache for artists. Itā€™s hard enough to get them to understand they need to commit/update files with SVN to get things synced, explaining them the differences between commit and pushing, fetch and pulling feels like trying to explain quaternions to a group of lawyers. And thatā€™s using a GUI client which abstracts the stage area, I wouldnā€™t even dare try to begin explaining the concept of ā€œstagingā€ (which is basically a 3rd layer where your changes can live).

Having the entire history locally can be an issue on large projects. LFS somewhat mitigates this, as itā€™s ā€œpruneā€ functionality keeps around only the data needed for the last couple commits, but pruning is something you need to do manually AFAIK. Still, in my experience with LFS you get a similar disk use as SVN, except thereā€™s no partial checkouts in git. For truly massive projects, Perforce is the only one that doesā€™t keep any duplicated files around and allows partial checkouts.

Branching and merging is, of course, much more robust in git than in SVN. But it can still get confusing if youā€™re not familiar with what terms like ā€œHEADā€ and ā€œREMOTEā€ actually mean.

It also doesnā€™t help that I canā€™t seem to find a ā€œperfectā€ GUI client: each one seems to have a weakness of some sort, be it performance, or being too simple, or being too complicated. The best one I found is Fork, which is actually a paid client ($50) with an ā€œunlimitedā€ free trial. It makes git a lot more pleasant to work with for me because:

  • It has an option to auto-stash local changes then re-apply them when pulling. This makes getting remote changes virtually as simple as in SVN and Perforce.
  • It also has an option to rebase instead of merging when pulling. This creates a clean commit history without ā€œmerge commitsā€ all over the place.

TortoiseGit can be nice for artists, but it has a fatal flaw IMO: it allows you to pull on top of local unstaged changes, and if any of the files in the pull is also modified locally it will create a merge commit which contains an unholy mix of all your local changes and the pulled in changes with no way of telling which is which after the fact.

Some people swear by git flow, but I much prefer trunk-based development due to it being friendlier to CI.

3 Likes
5

Yeah I have stuck to ā€˜trunk-basedā€™ dev!
Simplicity vs features debateā€¦

Yeah this is where Git pushed me to have to learn extra and not sure why I need 2 forms of commit and 2 updates!
Well because local repoā€¦
Simplicity vs features debateā€¦

Yep after trying others I settled on Tortoise for now as it plays similarly to TortoiseSVN, but thanks for warning!
Unfortunately while commit is easy, push is a lot less nice than svn all-in-one commit. For starters it does not remember my last push settings so I have to learn what is up thereā€¦ not spent much time on it

6

If I remember correctly it was the ease of teaching our non-programmers, and that some shared hosting providers included it in their base package. Which was great because it got you a domain, website, and repository all for just $10/mo.

1 Like
7

SVN is better for big, binary files and simpler to handle for non-coders.
Git has more features and better for handling code (although we usually donā€™t really use that much during Unity development, but it depends on what youā€™re doing, obviously).

If you can get away with SVN, I would go with that otherwise use Git.

8

Iā€™ve honestly been tempted to write my own. Iā€™d love to be able to set client-side rules about what to do with certain files (e.g. ā€œalways overwrite changes to this file with updates from the server without nagging me about itā€).

9

I would not say that Git is bad for binary files. I have done a test and pushed a 75GB Unreal Engine project to Azure Devops. Furthermore, I also made a video about that.
Git can be bad when configured wrong. Pushing binaries without configuring LFS is a total nightmare but if you do it correctly at the beginning it should not be a problem. Another thing about Git is that hosting providers like GitHub or GitLab can get expensive on file storage. I see more people using Azure Devops from Microsoft because they simply have no limits on LFS storage.
Git has a terrible UX for non artists. You can look at Anchorpoint, a file browser that we build, which has a Git integration for artists. I donā€™t recommend it for coders (they should go for SourceTree or GitKranken) but for the artist in the team, it should be fine.

10

Thereā€™s one thing that I missed. You donā€™t have to worry about misconfiguring SVN. You just use it.

11

My development background coming mostly outside of game development, Iā€™m very used to Git and have always used it from the command line. I did the switch from SVN to Git I think back in 2010 or so and personally could not imagine switching back.

Both have their use cases and work flows, but Iā€™m just a too big fan of the flexible and easy branching of Git. And managing releases with tags etc.

And what revolutionised my Git usage was learning about the git reflog command. Basically allows you to see all local branch updates and changes, so no matter what kind of mess you have accidentally gotten into (in your local branch that is), you can always get out of it with git reflog

1 Like