Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
It isn't that you have all your source code locally, it is that you have the entire repository history locally. This makes all repository interactions other than server synchronization much faster. –  stonemetal Oct 19 '12 at 19:37

5 Answers 5

up vote 65 down vote accepted

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.

share|improve this answer
8  
This is a very nice answer and really hits home with "...risk breaking the build for other people or suffer prolonged local development without any source control..." –  cspray Oct 19 '12 at 14:35
1  
@cspray: Thanks! I'm sure there are other benefits as well, but that is the greatest pain I had with Svn. –  Goran Jovic Oct 19 '12 at 15:09
    
git FTW (8 more to go...) –  Trevor Boyd Smith Oct 19 '12 at 18:32
    
one major benefit of the local repository is that all your changes can be committed locally before any merging (from remote) takes place. With svn I've had a couple botched merges that ultimately required a good deal of time to recover from because my local changes were not backed up elsewhere. –  Mr.Mindor Oct 19 '12 at 19:31
1  
@Giorgio: Try it and you'll know :) Seriously, I don't think I've ever managed to do that without problems (apart from doing a completely manual merge, which kind of defeats the purpose of the tool) –  Goran Jovic Oct 20 '12 at 8:01

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
1  
@Murph Thanks. That was essentially what I meant. I tried to clarify. –  Amenti Oct 19 '12 at 14:26
    
It's not just a question of if you have a network connection to the server or not; local IO is much faster and lower latency than network IO which makes examining history or blaming a file much faster (TrotiseSVN blame warning "Please wait - this can take several minutes. Seriously!"). The tradeoff is that having all the history local can require a lot more disk space in larger repositories; this can be problematic on laptops were you can't just add an extra drive to supplement a smaller non-bank-breaking SSD. –  Dan Neely Oct 19 '12 at 20:28

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.