It's more about what your organization uses.
At the end of the day, they both do the same thing. They store your updated files in one location. With git, everything is in the cloud. With SVN, you usually have to go to someone's server and upload or download from there. That being said, there are cloud SVN servers as well.
With GIT you can absolutely host your own "remote" server (local office network, internet, wherever) you don't have to use github and bitbucket for your remote. You can just install a package that goes onto a linux server. (probably windows too? no idea)
Also there are cloud SVN hosts out there. I've used this before...
https://www.assembla.com/subversionThe fundamental difference is that GIT always has 2 repository levels. local and remote. While SVN just has 1 repository that everyone in the project uses, and they check out specific versions of files in specific parts of the repo to work on... With GIT, you local repo is the thing you work on (ie commit changes to) and it contains your ENTIRE remote repository. Then you regularly push your local repo up to the the remote repo which gives you your off-computer backup so you're not hanging everything off a single disk drive on your laptop.
This fundamental difference means that if something critical happens to your master GIT repo you will have multiple copies of it in multiple other places to recover from.... SVN gives you one single master repo and people are always needing to connect to that, wherever they are, in order to have configuration management of what they are working on. And if that master repo is destroyed with no backup, you are in very deep very sticky poo.
This also enables all sorts of workflows and arrangements of your repository system..
here's a good writeup of what sorts of workflows you can have when using GIT.
https://www.atlassian.com/git/tutorials/comparing-workflowsI like gitflow and forking workflows for firmware and software, but it depends on how your team is arranged. gitflow still needs everyone to use the same repo all the time, and have some understanding of what everyone else is doing. Forking needs someone to be the master who is responsible for importing and checking all the different changes from everyone else's remote repos when asked.
Apparently the Linux kernel project is run with a massive hierarchical forking workflow. It has chains of people with responsibility for different aspects at different levels, all responsible for merging any changes below them and propagating changes up the chain when their responsibility is taken care of.
From using both (and this is just from my experience at different organizations, so your experience may differ), SVN encourages 1 local copy and committing changes when you are done. Git encourages you to make branches. At the end, you could have 5 different branches and you commit to that branch as you please. This works well for software. You can do the same thing in SVN, but it is discouraged (not sure why).
git branches are completely invisible to the file system. you have your working copy that your software tools see, and that's it... you navigate branches in GIT itself. you pull out the one you want to see, merge with the other one you want to merge with, put that merged branch back, then pull out another branch to work with...
my understanding of SVN branches is it's entirely on the user to make and manage them inside the SVN working folder structure - ie, you make parallel folder structures for branches and operate on whatever folder branch you need.
As a result git branches require a bit of automation to make them manageable... so they work well with things like source code, that are well structured text. Where if there's an edit collision (ie 2 different edits of the same thing in 2 different branches you want to merge) you can visually diff them and make a decision about what the merged version of the branches needs to be to work.
With something like a PCB file (even one in ASCII!) looking at that diff in a text editor will make no sense at all. so you really should be very careful to use branches in GIT for Altium projects - unless you love pain.... (or want to see if altium's built in visual file diff will work well enough to save you)
A limited version of the "feature branch" in the git workflows link above could work.... have a single release branch, then whenever you want to do any work, you start an "under change" branch, where you can go mad and commit changes all day long, push them to the remote whenever you feel like it... Then when you have finished all changes and checked all your release checkboxes, and want to do another release the "under change" branch basically merges in over the top of the (completely untouched since branching happened!) release branch and replaces all the release branch file states with its exact states. no file level merging needed..)
Meanwhile, anyone needing the last release version of a project even while you are actively developing the next version knows just where to get it... clone the remote repo, checkout the master branch. done. (most probably though, if it's a released version of the project they need, they should be looking for RELEASE FILES in a PRODUCTION RELEASE FOLDER, not design files in a design repository but that's another 5 page rant for another time...)
With Altium, you can use it with git, it is just not integrated. I use SVN with Altium, but I do not use what is integrated in Altium itself (does not play well with our SVN server). So in reality, I think the integration is only a big deal if you want to be integrated with Altium Vault as well, but even then, there are probably ways around it.
Yep! I'm keen to see exactly what altium does with GIT and how it's implemented as at a low level the GIT model is fundamentally different to SVN and vaults capabilities. If it works for me, I'll probably use it, but if it's too simplified or is going to clash with how I like to to my repos, I'll just stick with commandline git. Even built for purpose GUI tools like sourcetree can make a big ugly mess in the name of providing abstractions to simplify your git workflow for you.
Home
Help
Search
Login
Register
