I’m only going on what I’ve read on SO, so forgive me, but all I read says that one major advantage of Git over Subversion is that Git gives all the source code to the developer locally, not having to do anything on the server.
With my limited using of SVN and TortoiseSVN, I had all the source code, or at least I thought I did. For example, I have a website. I upload it to SVN. I am still running my website locally, aren’t I? If someone submits a change and I’m not connected, it wouldn’t matter if I had Git or not, until I reconnect to the server.
I do not understand. I’m not asking for a rehash of one vs. the other except this one point.
1
The premise you are questioning really is wrong:
that one major advantage of Git over Subversion is that Git gives all the source code to the developer locally
With both Subversion and Git you have your source code locally. With Git you have both your source code and a repository on your local machine.
It goes something like this.
Subversion:
Your code <-> The Repository
Git:
Your code <-> Your local repository <-> A remote repository (… <-> another remote repo, and so on)
One benefit you get from this structure is that you can still use source control and commit your local changes to your local repository without disturbing the work of other team members (with whom you share the remote repository).
With Subversion you’d have to either risk breaking the build for other people or suffer prolonged local development without any source control which ends with a huge commit (or more likely a revert).
With Git, on the other hand, you’d feel free to commit these changes to your local repository, view logs and diffs or your changes, and only when you feel it is ready to be shared with the team push the changes from the local repository to the remote one.
8
Git or Mercurial store your whole repository locally with all revisions and named branches. Subversion only stores one – usually the Head Revision. So with Git and Mercurial you can access the full repository (i.e. your current source code and its history) even when your network breaks down with SVN you are restricted to the last revision you updated to.
3
The short answer is this: with git you have all of your source code, with subversion you have all of the most recent version of your source code.
Git keeps a copy of the entire history of your repository locally. With subversion the entire history is on a server.
I think what you may be getting at is that with SVN, all your actions require communication with the server, where as GIT does not. With SVN, if you want to branch, you branch on the server and pull down that branch. With GIT, you could create a local branch without ever having the “server” know about it.
You’re correct in saying that you have the source code with both SVN and GIT, but with GIT, there doesn’t have to be a centralized server that contains the source code as well. With GIT, you may be the ONLY person with the source code, yet still be able to do all the functions that you would with a typical VCS.
I’ve heard arguments against GIT, and I think this may help with your question, saying that since you’re not required to commit to a central repo, you own your source code until you have committed and pushed it to your server, if you have one. With SVN, the only way to have the version control is by committing to the server, but with GIT, you could potentially keep everything on your local machine and if any goes wrong, you “could lose everything” even though you could just as easily lose all your changes with SVN if you didn’t commit and your HDD crashed as well.
saying that since you’re not required to commit to a central repo, you
own your source code until you have committed and pushed it to your
server, if you have one. With SVN, the only way to have the version
control is by committing to the server, but with GIT, you could
potentially keep everything on your local machine and if any goes
wrong, you “could lose everything” even though you could just as
easily lose all your changes with SVN if you didn’t commit and your
HDD crashed as well.
If you push daily, then the risk should be small.
But if you are forced to commit daily to SVN server, then at the end of the day, you may make everything in a single large changeset, which does not separate every change into small steps.
With git, you are encouraged to make multiple small commits.
When pushing, if merging is required, than try to merge and push. If you cannot merge at the moment, you can push to a new branch or another repository on the server.