From my own experience, and that was 10 years ago, here are some personal thoughts on the subject.
SVN puts hidden subfolder into every subfolder in your project, while Git keeps all the the data it needs in single .git in project root directory. Very annoying when you are trying to upload something with FTP
I also seem to remember SVN always copied all files instead of changes for some reason, so it took a lot more space.
Again I don't know if SVN has changed since, but with Git you could commit on your local all day long, then push changes when you want, and it wouldn't mess things up between you and co-workers, while I believe SVN you had to keep it synced all the time?
While Git workflow can get a bit tricky, you can use common conventions like gitflow, but if your team only needs to share changes between members, you all can just push/pull from master.
As for choosing between Git or Mercurial, if you use a GUI tool like Sourcetree, that can work with both, doesn't matter what engine you use per say, as you won't touch command line.
That might be, I'm pretty sure you can move files from one folder to another outside git CLI (I know there's specific git command for it as well), and git figures out that file was moved and keeps history intact.
SVN puts hidden subfolder into every subfolder in your project
This hasn't been the case for quite a long time. You now have a single .svn in the root, just like with git.
I also seem to remember SVN always copied all files instead of changes for some reason, so it took a lot more space.
The .svn contains a "pristine" copy of the file in your workspace. This is an exact copy of the file when checked out. It is just one version of the file.
Git on the other hand stores all versions, from the cloned repo. Unlike SVN, GIT compresses the files. For a repo with a few versions it will be smaller, but once the repo grows it will start to consume more space than SVN does.
Again I don't know if SVN has changed since, but with Git you could commit on your local all day long, then push changes when you want, and it wouldn't mess things up between you and co-workers, while I believe SVN you had to keep it synced all the time?
SVN is still centralized, committing is always to the server. You won't mess things up between you and your co-workers unless people are working on the same files.
From my own experience, and that was 10 years ago, here are some personal thoughts on the subject.
SVN puts hidden subfolder into every subfolder in your project, while Git keeps all the the data it needs in single .git in project root directory. Very annoying when you are trying to upload something with FTP
I also seem to remember SVN always copied all files instead of changes for some reason, so it took a lot more space.
Again I don't know if SVN has changed since, but with Git you could commit on your local all day long, then push changes when you want, and it wouldn't mess things up between you and co-workers, while I believe SVN you had to keep it synced all the time?
While Git workflow can get a bit tricky, you can use common conventions like gitflow, but if your team only needs to share changes between members, you all can just push/pull from master.
As for choosing between Git or Mercurial, if you use a GUI tool like Sourcetree, that can work with both, doesn't matter what engine you use per say, as you won't touch command line.
SVN annoyed me for the exact same reason: folders everywhere... "Git tracks files not folders", isn't that a claim somewhere git-related?
That might be, I'm pretty sure you can move files from one folder to another outside git CLI (I know there's specific git command for it as well), and git figures out that file was moved and keeps history intact.
Yes, I think the quote I mentioned refers to empty folders which aren't tracked without some trickery like a
gitkeepfile or something similar.This hasn't been the case for quite a long time. You now have a single .svn in the root, just like with git.
The .svn contains a "pristine" copy of the file in your workspace. This is an exact copy of the file when checked out. It is just one version of the file.
Git on the other hand stores all versions, from the cloned repo. Unlike SVN, GIT compresses the files. For a repo with a few versions it will be smaller, but once the repo grows it will start to consume more space than SVN does.
SVN is still centralized, committing is always to the server. You won't mess things up between you and your co-workers unless people are working on the same files.
Like I said it was quite long time ago, would be surprised if SVN didn't improve. Good to know.