Why You Should Switch from Subversion to Git(carsonified.com)
carsonified.com
Why You Should Switch from Subversion to Git
http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/
78 comments
I didn't experience pain either... until I used git for a while. Then I realized all the pain that I was suffering but wasn't aware of.
> The amount of time people spend blogging about how great git is could be surely put to better use.
Maybe they're spending so much time blogging because git really is that good?
> The amount of time people spend blogging about how great git is could be surely put to better use.
Maybe they're spending so much time blogging because git really is that good?
While I can understand how git is better for the majority of use-cases, I found that it was far less suitable than SVN for what I want to do. I used git for a while (3-6 months) and then switched BACK to using SVN. It's true I didn't experience pain until I started using git. That's when the pain started.
First, as I said, my use case is highly non-standard. I'm the only developer on my project, so I don't have to worry about collaborators. I do my work on a lot of different computers, so it turns out that (for me) one of the biggest advantages provided by version control is effectively synchronizing source code between systems, many of which get erased (e.g. new OS installed ) on a regular basis, all of which have internet access. It is important that I be able to quickly and simply set up a development environment on a new system -- a somewhat unusual requirement, I realize. Under these circumstances the primary advantage -- not just of git, but any DVCS -- becomes a major disadvantage. The whole point of DVCS is that the ability to commit is separated from the ability to update the central repository (git push), where they are the same in centralized VCS. However... I ALWAYS want to push when I commit. If I commit to a local repository on a machine that gets wiped, it does me no good. It needs to get updated in the central, online repository every time. This can be done with a short simple shell script, of course, but remember: I need it it to be as simple as possible to set up a new development environment. This adds an extra step, and if I neglect it, I can lose a lot of work. If I use SVN, I simply don't have to worry about it. It's automatic.
Another feature of SVN that I like, that's impossible with DVCS: revision numbers. With SVN, revision numbers increase sequentially from 1 to whatever number commit the last one was. DVCS can't do revision numbers because you can't determine the sequence of commits until after the commits are made (everyone has their own repository!). Being able to refer to r378 is a LOT nicer than referring to an arbitrary hexadecimal identifier. Having commit identifiers that convey information is a huge plus.
For me, these reasons are enough to outweigh the advantages of having access to repository history while offline and the better handling of branching that git offers.
First, as I said, my use case is highly non-standard. I'm the only developer on my project, so I don't have to worry about collaborators. I do my work on a lot of different computers, so it turns out that (for me) one of the biggest advantages provided by version control is effectively synchronizing source code between systems, many of which get erased (e.g. new OS installed ) on a regular basis, all of which have internet access. It is important that I be able to quickly and simply set up a development environment on a new system -- a somewhat unusual requirement, I realize. Under these circumstances the primary advantage -- not just of git, but any DVCS -- becomes a major disadvantage. The whole point of DVCS is that the ability to commit is separated from the ability to update the central repository (git push), where they are the same in centralized VCS. However... I ALWAYS want to push when I commit. If I commit to a local repository on a machine that gets wiped, it does me no good. It needs to get updated in the central, online repository every time. This can be done with a short simple shell script, of course, but remember: I need it it to be as simple as possible to set up a new development environment. This adds an extra step, and if I neglect it, I can lose a lot of work. If I use SVN, I simply don't have to worry about it. It's automatic.
Another feature of SVN that I like, that's impossible with DVCS: revision numbers. With SVN, revision numbers increase sequentially from 1 to whatever number commit the last one was. DVCS can't do revision numbers because you can't determine the sequence of commits until after the commits are made (everyone has their own repository!). Being able to refer to r378 is a LOT nicer than referring to an arbitrary hexadecimal identifier. Having commit identifiers that convey information is a huge plus.
For me, these reasons are enough to outweigh the advantages of having access to repository history while offline and the better handling of branching that git offers.
If adding a shell script to your development environment results in pain every time you need to set it up, that says you haven't automated setting up the environment. One great way to automate it is to put all such scripts (surely this would not be the only one?) and other files in a version controlled repository; then you just have one more thing to check out.
(If checking out one more thing results in pain, you should think about automating the checkout too... This line of thinking has resulted in me keeping everything in git and using a single `mr` command (google will find it) to check out all my respositories when I'm setting up a new account.)
Revision numbers are not impossible with DVCS; bzr has repo-local revision numbers. But once a number becomes longer than 3 digits, I cut and paste it anyway; if I'm already pasting, the longer size of git's sha1s doesn't matter.
(If checking out one more thing results in pain, you should think about automating the checkout too... This line of thinking has resulted in me keeping everything in git and using a single `mr` command (google will find it) to check out all my respositories when I'm setting up a new account.)
Revision numbers are not impossible with DVCS; bzr has repo-local revision numbers. But once a number becomes longer than 3 digits, I cut and paste it anyway; if I'm already pasting, the longer size of git's sha1s doesn't matter.
Also, you only need as much of the hash as neccesary to identify the commit. Generally 5 or 6 digits is long enough.
How can you not be aware of pain? If I was wasting time on a laborious task, I think I'd know about it and think of a better way. Care to share an example from your experience?
During my average day, I probably spend a few minutes total messing with svn. For my usecase, it's already optimum. The only way I could reduce that time is to not put in any commit messages :/
During my average day, I probably spend a few minutes total messing with svn. For my usecase, it's already optimum. The only way I could reduce that time is to not put in any commit messages :/
How can you not be aware of pain?
Anecdotally, this is fairly common. I have known people that did not realize they had fairly bad back pain until they went to the doctor for something else and had it treated.
Sometimes, it is only in absence of something that we really notice it, especially if it is truly chronic. I suspect most people have gone somewhere with a fairly loud background noise. At first they may notice it, but after being there for a while they may forget about it and may even forget it was ever there. But they will notice and realize how annoying it was if that noise ever stops.
Anecdotally, this is fairly common. I have known people that did not realize they had fairly bad back pain until they went to the doctor for something else and had it treated.
Sometimes, it is only in absence of something that we really notice it, especially if it is truly chronic. I suspect most people have gone somewhere with a fairly loud background noise. At first they may notice it, but after being there for a while they may forget about it and may even forget it was ever there. But they will notice and realize how annoying it was if that noise ever stops.
I don't think the analogy holds here though.
I type 'svn commit' 'svn update', it works. quickly.
For me, it's like suggesting I change from using 'cd' to change directory, to using 'awesome-cd' to change directory :/
I type 'svn commit' 'svn update', it works. quickly.
For me, it's like suggesting I change from using 'cd' to change directory, to using 'awesome-cd' to change directory :/
I have never used SVN or Git (I use Hg at home and VSS at work), so I can't say there.
What I can say is that I didn't realize how painful Java was for me until I started learning Python. That may be a closer analogy, though still not perfect.
What I can say is that I didn't realize how painful Java was for me until I started learning Python. That may be a closer analogy, though still not perfect.
Why would I switch from horses to these new-fangled automatic carriages? Horses get me where I need to go.
Here is an example from my experience:
Sometimes when I'm developing, and ready to commit something I notice I've made a few unrelated changes/bugfixes. I could just commit the whole thing at once, but that makes merging a hassle because I probably want to merge those bugfixes to trunk much sooner than any code which implements a new feature. So, I would need some way to commit only certain diff chunks from each file.
I understand from "http://www.gitcasts.com/posts/interactive-adding that git can do that. So far it hasn't been incentive enough to switch, but it's one example of the pain of subversion.
Sometimes when I'm developing, and ready to commit something I notice I've made a few unrelated changes/bugfixes. I could just commit the whole thing at once, but that makes merging a hassle because I probably want to merge those bugfixes to trunk much sooner than any code which implements a new feature. So, I would need some way to commit only certain diff chunks from each file.
I understand from "http://www.gitcasts.com/posts/interactive-adding that git can do that. So far it hasn't been incentive enough to switch, but it's one example of the pain of subversion.
Try 'git add -p', it's a lot easier than interactive mode.
I don't know how, I just realized it after the fact. One good example is the use of branches. I began with CVS and switched to Subversion later. I always avoided branches because keeping track of merging points and resolving conflicts is a pain. I used to think that branches cause more problems than they solve.
Until I switched to git. Only then did I realize how much pain I was suffering by avoiding branches. Now I use branching all the time.
I guess it's because I had nothing to compare to. I didn't know that branches can be done well.
Until I switched to git. Only then did I realize how much pain I was suffering by avoiding branches. Now I use branching all the time.
I guess it's because I had nothing to compare to. I didn't know that branches can be done well.
When your server's drive crashes, and you lose all of your history... you'll feel some pain. Backups help, but not as good as git does.
See what happened with _why? He nuked everything, but none of it really went away. With CVCS, the community would have lost everything.
See what happened with _why? He nuked everything, but none of it really went away. With CVCS, the community would have lost everything.
> Maybe they're spending so much time blogging because git really is that good?
That may be, but they're the only community I see being extremely in-your-face about their tool and how it's clearly beating the pants off everything else. Personally, I'd be more interested why they feel the need to declare its goodness so loudly, when if it really is as awesome as these articles make it sound then it'll spread like wildfire by word of mouth.
emacs changed the way I write code, and made me wildly efficient compared to before I used it. That doesn't mean I'm going to go and start browbeating people into using it. The git community seems to be blind to the notion that git (as wonderful as it is) might not be for everyone.
That may be, but they're the only community I see being extremely in-your-face about their tool and how it's clearly beating the pants off everything else. Personally, I'd be more interested why they feel the need to declare its goodness so loudly, when if it really is as awesome as these articles make it sound then it'll spread like wildfire by word of mouth.
emacs changed the way I write code, and made me wildly efficient compared to before I used it. That doesn't mean I'm going to go and start browbeating people into using it. The git community seems to be blind to the notion that git (as wonderful as it is) might not be for everyone.
All these people shouting about it are are spreading it by word of mouth and it has spread like wildfire. Maybe it is time to consider if it really is that good?
How is an article on someone elses website "in-your-face"? Nobody's pointing a gun at you and forcing you to read it. If blogging about it is "in-your-face" then what do you consider an acceptable method to tell others about a great tool?
I don't feel any pain.
Have you asked your colleagues if your use of svn is causing them pain?
Or maybe you don't have colleagues. If you don't, that's fine. I used to work mainly by myself, and back then I thought as you do. Live and let live, I said. Choose the tool that works for you, I said. Hell, use CVS if you really want to, I said.
But now I work at a company that uses svn. And my coworkers' lack of productivity is also my lack of productivity. Every week or so there's some annoying issue: Programmer A doesn't commit the fix right away, because they made that fix in the middle of some other set of changes that would otherwise break the build, and they don't want to take the time to disentangle things. Programmer B commits to Branch Q, which is bad because the third-party svnmerge tool has been set to pull from Branch P to branch Q and not the other way around. And that's assuming there is a branch Q, because even with svnmerge everyone is scared to death of making branches. It's just so painful to reconcile them later.
So ultimately you have to make a choice: Are you going to sit around and allow your colleagues to waste time on your team's behalf? Or are you going to try to raise the bar a little by forwarding them an article about a tool that might solve the team's problems? Or are you going to quit and get a job with a company full of people who care about their tools?
P.S. For the record: Everyone at my own company is well aware of git, and bzr for that matter. But you're right: There are more urgent things to do in life than tinker with your VCS, so switching isn't a priority. And, as others will point out, there are little things about SVN, built up during its decade-long history, that haven't made it into git yet, and one of those might be a showstopper. So we may be gritting our teeth for a while yet.
Have you asked your colleagues if your use of svn is causing them pain?
Or maybe you don't have colleagues. If you don't, that's fine. I used to work mainly by myself, and back then I thought as you do. Live and let live, I said. Choose the tool that works for you, I said. Hell, use CVS if you really want to, I said.
But now I work at a company that uses svn. And my coworkers' lack of productivity is also my lack of productivity. Every week or so there's some annoying issue: Programmer A doesn't commit the fix right away, because they made that fix in the middle of some other set of changes that would otherwise break the build, and they don't want to take the time to disentangle things. Programmer B commits to Branch Q, which is bad because the third-party svnmerge tool has been set to pull from Branch P to branch Q and not the other way around. And that's assuming there is a branch Q, because even with svnmerge everyone is scared to death of making branches. It's just so painful to reconcile them later.
So ultimately you have to make a choice: Are you going to sit around and allow your colleagues to waste time on your team's behalf? Or are you going to try to raise the bar a little by forwarding them an article about a tool that might solve the team's problems? Or are you going to quit and get a job with a company full of people who care about their tools?
P.S. For the record: Everyone at my own company is well aware of git, and bzr for that matter. But you're right: There are more urgent things to do in life than tinker with your VCS, so switching isn't a priority. And, as others will point out, there are little things about SVN, built up during its decade-long history, that haven't made it into git yet, and one of those might be a showstopper. So we may be gritting our teeth for a while yet.
How does git make programmer A want to disentangle the fix?
How does git keep Programmer B from making changes against the wrong base? (Admittedly, git may make it easier to move that fix from the wrong base to the right one, but it doesn't make it harder to make the mistake; if anything, a prolifiration of branches an independent lines of development makes it easier to make that mistake, not harder.)
How does git make merging easier? Doesn't it do a traditional three-way merge, just like svn? And it seems like in DVCS you have more merging, not less...
How does git keep Programmer B from making changes against the wrong base? (Admittedly, git may make it easier to move that fix from the wrong base to the right one, but it doesn't make it harder to make the mistake; if anything, a prolifiration of branches an independent lines of development makes it easier to make that mistake, not harder.)
How does git make merging easier? Doesn't it do a traditional three-way merge, just like svn? And it seems like in DVCS you have more merging, not less...
* interactive commits let you commit only parts of what you're working on. It's really easy just to commit the lines that were involved with the fix, and leave everything else alone.
* Even the best tools can be used wrong.
* It makes merging easier by making it work fast and work well. There's a lot more merging, it's not painful!
* Even the best tools can be used wrong.
* It makes merging easier by making it work fast and work well. There's a lot more merging, it's not painful!
"How does git make programmer A want to disentangle the fix?"
Wrong question; the correct question is "Why does SVN make the programmer not want to disentangle the fix?" The answer is that SVN makes it a royal pain in the ass. Not impossible. Nothing is impossible. But it's a royal pain in the ass. Git makes it roughly as hard as it should be; there's a certain amount of essential complexity, but it lowers the accidental complexity to something feasible. (I use Fred Brook's "accidental" vs "essential" complexity terminology from the Mythical Man Month; if you don't know what that is, hie thee hence to amazon and acquire the Mythical Man Month.)
The reason I phrase it this way is that it's really a given that the fix should be disentangled; even SVN proponents will tend to agree with this as a matter of principle. So the question is, why have we all just gotten used to not bothering?
"How does git make merging easier?"
Again, correct question is "How does SVN make merging hard?" and the answer is "in numerous ways". However, in git, it actually works the way it always should have worked. SVN brings way too much accidental complexity to the task of merging, which is evidenced by the way people avoid it like the plague, whereas the exact same people have no problem using git for it.
"It sounds like you're handwaving!" - OK, you didn't say this but I see it coming. The answer is either Google to someone treating this subject more fully (it's not that hard to find), or try it yourself; I see no point in repeating such people's work in a limited HN comment. (Many of them have diagrams and such.) It is not comparable. It is a night-and-day difference unless you are the only person using your SVN repository, and even then git is still nicer.
Wrong question; the correct question is "Why does SVN make the programmer not want to disentangle the fix?" The answer is that SVN makes it a royal pain in the ass. Not impossible. Nothing is impossible. But it's a royal pain in the ass. Git makes it roughly as hard as it should be; there's a certain amount of essential complexity, but it lowers the accidental complexity to something feasible. (I use Fred Brook's "accidental" vs "essential" complexity terminology from the Mythical Man Month; if you don't know what that is, hie thee hence to amazon and acquire the Mythical Man Month.)
The reason I phrase it this way is that it's really a given that the fix should be disentangled; even SVN proponents will tend to agree with this as a matter of principle. So the question is, why have we all just gotten used to not bothering?
"How does git make merging easier?"
Again, correct question is "How does SVN make merging hard?" and the answer is "in numerous ways". However, in git, it actually works the way it always should have worked. SVN brings way too much accidental complexity to the task of merging, which is evidenced by the way people avoid it like the plague, whereas the exact same people have no problem using git for it.
"It sounds like you're handwaving!" - OK, you didn't say this but I see it coming. The answer is either Google to someone treating this subject more fully (it's not that hard to find), or try it yourself; I see no point in repeating such people's work in a limited HN comment. (Many of them have diagrams and such.) It is not comparable. It is a night-and-day difference unless you are the only person using your SVN repository, and even then git is still nicer.
> How does git make programmer A want to disentangle the fix?
From experience, I'd say it makes the process of doing so easier. In git you can: 1. commit a portion of the code, even a portion of a single file using git add --interactive 2. stash your current changes, re-make the change needed, commit, then unstash and keep working
> How does git keep Programmer B from making changes against the wrong base?
Making it easier to move the fix is exactly the point. You can't make it impossible to make mistakes, but you can make them less disastrous. Also, you can easily revert the fix in the wrong branch or remove it entirely if you haven't shared your changes.
> How does git make merging easier?
I was too scared to make branches in other systems, but my guess is that rebase is a significant part of it. If you're rebasing fairly frequently the changes you're making shouldn't diverge too much, and it makes the actual merges trivial.
You gain a lot from being able to manipulate the history of your repository. The unfortunate thing is that the history itself isn't version controlled, so you can't manipulate the history once you've shared it with other people.
From experience, I'd say it makes the process of doing so easier. In git you can: 1. commit a portion of the code, even a portion of a single file using git add --interactive 2. stash your current changes, re-make the change needed, commit, then unstash and keep working
> How does git keep Programmer B from making changes against the wrong base?
Making it easier to move the fix is exactly the point. You can't make it impossible to make mistakes, but you can make them less disastrous. Also, you can easily revert the fix in the wrong branch or remove it entirely if you haven't shared your changes.
> How does git make merging easier?
I was too scared to make branches in other systems, but my guess is that rebase is a significant part of it. If you're rebasing fairly frequently the changes you're making shouldn't diverge too much, and it makes the actual merges trivial.
You gain a lot from being able to manipulate the history of your repository. The unfortunate thing is that the history itself isn't version controlled, so you can't manipulate the history once you've shared it with other people.
One could also use SVN and GIT together. That might solve a part of the problem with not submitting fixes because of being in the middle of other set of changes. Develop using GIT locally and submit to SVN repository when ready.
What is experience of HN readers with using a combination of centralised and distributed VCS together? Have you used it and in what situations, if any, is it useful?
What is experience of HN readers with using a combination of centralised and distributed VCS together? Have you used it and in what situations, if any, is it useful?
We use git-svn extensively at work. It is pretty good at allowing us to keep our central core dev branch going on SVN with numerous teams not using git-svn, while allowing us to do all our release branching and such in git. I would not be happy to use it in a situation where we had multiple concurrent SVN branches, but then, I wouldn't care to be using SVN there either.
You really do get the bulk of the advantages; it's not perfect, and if you have to coordinate with someone not using git it can be a challenge, but it mostly works. People were briefly annoyed at our "patch bombs" but got over it.
You really do get the bulk of the advantages; it's not perfect, and if you have to coordinate with someone not using git it can be a challenge, but it mostly works. People were briefly annoyed at our "patch bombs" but got over it.
I just moved from a 4 man svn project to a 4 man git project. It took me a month before I didn't feel like an ass in git. I'm still not sure what I have gained. I know git is so powerful and does so many things, but I'm a simple user. To me version control is like a doormat: I pass it really quickly on the way into the house. If that's what it is to you git will not open up a new world. In fact it will just take you longer to become proficient and waste time that could otherwise be spent coding.
When you say you are a "user", are you not a programmer? If so, then you probably won't see much to be excited about.
If you are a programmer and you aren't seeing how source control helps you (and it sounds like you weren't seeing any particular benefit with SVN either), then you either don't have much experience, or are dangerously close to being the type of programmer who repeats the same year ten times, rather than acquiring ten years of experience. You really need to work on internalizing what source control allows you to do, git, svn, or otherwise. Not knowing what source control is good for is like a furniture maker wondering what a lathe is good for, beyond turning a simple cylinder. (Among other things, if there was a Furniture News, that's not the sort of comment that ought to be getting upvotes...)
Edit: Yes, nothing scores downmods like telling people that you need to know things to be a good developer. Guess what? You need to know things to be a good developer. Knowing what source control is and how to use it effectively is one of them. Downmodding me won't make that go away, nor will it magically make people who don't "get" source control better developers.
If you are a programmer and you aren't seeing how source control helps you (and it sounds like you weren't seeing any particular benefit with SVN either), then you either don't have much experience, or are dangerously close to being the type of programmer who repeats the same year ten times, rather than acquiring ten years of experience. You really need to work on internalizing what source control allows you to do, git, svn, or otherwise. Not knowing what source control is good for is like a furniture maker wondering what a lathe is good for, beyond turning a simple cylinder. (Among other things, if there was a Furniture News, that's not the sort of comment that ought to be getting upvotes...)
Edit: Yes, nothing scores downmods like telling people that you need to know things to be a good developer. Guess what? You need to know things to be a good developer. Knowing what source control is and how to use it effectively is one of them. Downmodding me won't make that go away, nor will it magically make people who don't "get" source control better developers.
jerf, using the analogy of the furniture builder:
-Your shop would be your OS.
-Your wood would be your programming language.
-Your lathe would be your IDE / text editor
-Your broom would be your source control system.
A furniture builder would use a broom to reset after a messy job and at the end of the day. That is about how I use source control. I've never worked on a huge open source project with lots of branching and merging. I've worked in small teams where we have one evolving version and that's all we really care about. SVN works fine for syncing and resolving conflicts.
If SVN is a broom, Git is a complicated vacuum cleaner. Perhaps more powerful, but when I started using it, I took me 10x longer to clean the floor. I learned CVS, Rational Clearcase, MS Source Safe and SVN on the first day and spent very little time thinking about them afterwards. While I liked SVN the best, they all did their job well enough. I'm now good enough at git that it's not a time sink, but I'm not sure what I really gained from it.
Furthermore, you may want to adjust your tone and try not to jump to conclusions. You probably can't intuit what kind of a person / developer I am from a single comment.
-Your shop would be your OS.
-Your wood would be your programming language.
-Your lathe would be your IDE / text editor
-Your broom would be your source control system.
A furniture builder would use a broom to reset after a messy job and at the end of the day. That is about how I use source control. I've never worked on a huge open source project with lots of branching and merging. I've worked in small teams where we have one evolving version and that's all we really care about. SVN works fine for syncing and resolving conflicts.
If SVN is a broom, Git is a complicated vacuum cleaner. Perhaps more powerful, but when I started using it, I took me 10x longer to clean the floor. I learned CVS, Rational Clearcase, MS Source Safe and SVN on the first day and spent very little time thinking about them afterwards. While I liked SVN the best, they all did their job well enough. I'm now good enough at git that it's not a time sink, but I'm not sure what I really gained from it.
Furthermore, you may want to adjust your tone and try not to jump to conclusions. You probably can't intuit what kind of a person / developer I am from a single comment.
I'm also surprised people are still arguing about this. I switched to Git so long ago I sometimes need to look at the man pages for SVN when I use it because I've forgotten how to do some things. IMHO unless you have a good reason to use SVN, you really should be using some kind of DVCS. SVN compared to Git/Mercurial/etc is like nano compared vim or emacs.
I do definitely consider "I'm already using SVN and I'm happy" to be a completely valid reason to use SVN because people should be free to use what they like.
But if that is your line of thought, keep in mind that you are making a concious decision to continue with a much less powerful tool and are not taking advantage of something that, if you put the time into learning it, would benefit you.
I do definitely consider "I'm already using SVN and I'm happy" to be a completely valid reason to use SVN because people should be free to use what they like.
But if that is your line of thought, keep in mind that you are making a concious decision to continue with a much less powerful tool and are not taking advantage of something that, if you put the time into learning it, would benefit you.
Serious question:
What benefits would a single developer working in isolation derive from using a distributed version control system?
And what if that developer was running an OS like Windows? Does git have first-class support for Windows?
Would such a developer still see any advantage to using git?
What benefits would a single developer working in isolation derive from using a distributed version control system?
And what if that developer was running an OS like Windows? Does git have first-class support for Windows?
Would such a developer still see any advantage to using git?
Git's easy branching is a huge benefit for working on new features/refactorings in isolation. It is much easier than SVN's.
Git works fine on Windows, take a look at: http://code.google.com/p/msysgit/
Git works fine on Windows, take a look at: http://code.google.com/p/msysgit/
I can't say for all distributed version control systems, but in case of git, it's extremely easy to setup a new repository. Create a new directory, type 'git init', and you're good to go. This compared to Subversion's insistence to setup a repo directory elsewhere and then checking that out. I save about 3 minutes (including time to ssh to a remote server to create the repository), but those 3 minutes feel very painful so I didn't create repositories until I've written a fair amount of code. Now I create a repository almost from the start.
Branching and merging is very useful even for single developers. It's not the number of developers, it's the size of the project. For larger projects I'll want to branch often to experiment with things. I can delete the branch after I'm done with the experiment.
As for Windows support: I've heard that Msys-Git is in a very good shape today. I haven't used it myself though.
Branching and merging is very useful even for single developers. It's not the number of developers, it's the size of the project. For larger projects I'll want to branch often to experiment with things. I can delete the branch after I'm done with the experiment.
As for Windows support: I've heard that Msys-Git is in a very good shape today. I haven't used it myself though.
No need to set up a central repository. Your full history resides in your working copy.
Still generalizing IMHO.
Nano fits a whole raft of use cases. For a lot of things, it's better and more suited than vim or emacs.
Similarly, a whole load of use cases, svn is more suited to the task at hand than git is.
Nano fits a whole raft of use cases. For a lot of things, it's better and more suited than vim or emacs.
Similarly, a whole load of use cases, svn is more suited to the task at hand than git is.
Name a use case where svn is more suited than git is. I for one can't think of a single one. At most they might be equivalent. More likely git will be one of:
* faster * more featureful
I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.
* faster * more featureful
I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.
1. Dealing with large art/graphics/asset repositories. Having every artist with a private 50GB+ repository is unmanageable (especially when the artists can't be bothered to understand why add->commit->push is necessary).
2. Dealing with SOX compliance with regard to shipping software. You are required to keep a lot of redundant compiled files around.
2. Dealing with SOX compliance with regard to shipping software. You are required to keep a lot of redundant compiled files around.
To me the only good reasons to use SVN at this point are cultural. For example, your project can't afford the time to make the switch, or your organization has some useful tools built around SVN that would cost time and money to replace.
Like I said earlier, "because I want to" is a also valid reason, just not a good one.
@axod, Git repos take up way less space on disk than SVN because its compression and diffing is much better than SVN's. This is one of the first things you read in most Git FAQ's. If you're not aware of that, it indicates you've barely given Git a serious look. If you haven't given it a serious look, I don't understand why you are arguing against it so passionately. I'm guessing you dislike the (admittedly annoying) hype around Git more than Git itself.
@axod, Git repos take up way less space on disk than SVN because its compression and diffing is much better than SVN's. This is one of the first things you read in most Git FAQ's. If you're not aware of that, it indicates you've barely given Git a serious look. If you haven't given it a serious look, I don't understand why you are arguing against it so passionately. I'm guessing you dislike the (admittedly annoying) hype around Git more than Git itself.
Put some videos in svn and in git. update them 100 times to different videos each time.
The git repos now has 100 separate sets of video files, which will compress poorly.
The svn checkout has one set of videos.
The svn local checkout is likely to be far smaller than the git one. Is the above true, or false. If false, why?
You're right though, I dislike the hype and the suggestion that it in some way matters. Sure, use revision control, but is it really going to speed up your software dev moving to something else? maybe, maybe not. Is it going to impact the chances of success for your startup? probably not.
The git repos now has 100 separate sets of video files, which will compress poorly.
The svn checkout has one set of videos.
The svn local checkout is likely to be far smaller than the git one. Is the above true, or false. If false, why?
You're right though, I dislike the hype and the suggestion that it in some way matters. Sure, use revision control, but is it really going to speed up your software dev moving to something else? maybe, maybe not. Is it going to impact the chances of success for your startup? probably not.
Yeah, you're right that in this case SVN would have a smaller checkout size. So if this is something that you need then SVN would be a clear winner here in terms of disk storage.
However, with the more typical usage pattern of a repository of mostly code and perhaps a handful of smallish binary files, Git is almost always going to have a smaller checkout size despite including the version history.
I also think in this case the difference is like being shot in the stomach, or being shot in the knee. Both SVN and Git are going to give you serious pain.
However, with the more typical usage pattern of a repository of mostly code and perhaps a handful of smallish binary files, Git is almost always going to have a smaller checkout size despite including the version history.
I also think in this case the difference is like being shot in the stomach, or being shot in the knee. Both SVN and Git are going to give you serious pain.
In the name of science I'm converting the Mibbit repos from svn to git to see what the size difference actually is on a typical repos (I don't have videos in there ;)
Be interesting to see if svn is really that inefficient...
Who knows, maybe I'll try a few git commands :/
Be interesting to see if svn is really that inefficient...
Who knows, maybe I'll try a few git commands :/
Awesome, it'll be interesting to see the results. Make sure you do
git repack -a -d -f --window=100 --depth=100
after converting from svn to git. Otherwise you'll have a lot of artifacts from the conversion lying around and the git repo will be HUGE.
(taken from http://marc.info/?l=git&m=120734745806416)
git repack -a -d -f --window=100 --depth=100
after converting from svn to git. Otherwise you'll have a lot of artifacts from the conversion lying around and the git repo will be HUGE.
(taken from http://marc.info/?l=git&m=120734745806416)
Thanks. I'll have a go. I'd be really surprised and impressed if the git repos is smaller than an svn checkout,
EDIT: Here's the results...
Subversion repository: 80M A Subversion checkout: 172M Git version: 121M
I'm surprised the subversion checkout is quite a bit larger, but it's not really enough to make me care all that much yet...
I do conceed that git compresses things well, although it's still quite a bit larger than the original svn repository.
EDIT: Here's the results...
Subversion repository: 80M A Subversion checkout: 172M Git version: 121M
I'm surprised the subversion checkout is quite a bit larger, but it's not really enough to make me care all that much yet...
I do conceed that git compresses things well, although it's still quite a bit larger than the original svn repository.
I think the fact that SVN adds almost 100 megs of crap to your checkout does suck. But yeah, I don't think it's a deal breaker. I switched to Git for the features; the smaller "checkout" sizes was just an additional benefit.
Thanks for posting your results, I think it's very cool that you are not a Git fan but took the time to really look into it.
Thanks for posting your results, I think it's very cool that you are not a Git fan but took the time to really look into it.
If you want to compare repository sizes you should compare the size of .git directory only.
Hm, only Subversion so far has good and "easy" GUI integration over all platforms. GIT's only failing on Windows, or Mercurial's on the Mac. For a multi-level of expertise, multi-platform, multi-disciplinary team (front-end, back-end, flash developers) working on Macs, Windows and Linux boxes, it seems to me SVN is still the path of least resistance. Much as I hate it.
One off the top of my head:
From my understanding, git has the entire repository locally. There's obviously going to be some instances where this isn't possible or desirable. For example, small netbook or mobile device with small storage or slow net connection, wants to participate in large project with massive repository history.
From my understanding, git has the entire repository locally. There's obviously going to be some instances where this isn't possible or desirable. For example, small netbook or mobile device with small storage or slow net connection, wants to participate in large project with massive repository history.
You can also only check out the history to a certain depth, if this is a problem.
[deleted]
When you want to lock binary files as "being edited". DVCSes by design cannot lock files.
edit: I'd also say that SVN integrates better with a lot of things than git/hg do.
edit: I'd also say that SVN integrates better with a lot of things than git/hg do.
[deleted]
The article is indeed for people who are pretty satisfied with svn. I don't think of the article as a waste of time because there are many people who don't know what are the advantages of git over svn.
I'm not sure why you were downmodded, but I upmodded you because I agree. I use subversion daily, and I love it. I've dabbled in git, I understand the strengths, but for me, its not worth spending the time to migrate all of my projects over there.
To borrow a concept from programming languages, svn is blub.
That's about as good an argument as saying only communists use svn.
So basically your argument is that the only people who can have a valid opinion about the usefulness of different rcs's are those using git :/
So basically your argument is that the only people who can have a valid opinion about the usefulness of different rcs's are those using git :/
I agreed with the first two sentences of your original post. People waste entirely too much time writing about git vs svn.
However, you are absolutely wrong here. The blub argument is not that you must use git to have a valid opinion about git. It is that you must grok the power of the features. You could have a reasonable background of modern version control by using Mercurial, DARCS, BitKeeper, etc, even if it didn't inform you perfectly about what git can do (rebase -i anyone?). However if you've only used SVN or CVS then you are completely in the dark. I'm sorry but it's the indisputable truth. It's like someone who's never programmed in anything but Java, explaining how LISP macros are of no use to them. As if they would even know what a macro could do for them.
However, you are absolutely wrong here. The blub argument is not that you must use git to have a valid opinion about git. It is that you must grok the power of the features. You could have a reasonable background of modern version control by using Mercurial, DARCS, BitKeeper, etc, even if it didn't inform you perfectly about what git can do (rebase -i anyone?). However if you've only used SVN or CVS then you are completely in the dark. I'm sorry but it's the indisputable truth. It's like someone who's never programmed in anything but Java, explaining how LISP macros are of no use to them. As if they would even know what a macro could do for them.
... and I'm absolutely aware of what git can do.
I'm not making an uninformed choice here, I know the fun things git can do, and I'm sure if I switched to git, I'd probably spend all day playing with its awesome features, then I'd probably write a blog post proclaiming how awesome it is.
Or, I could just continue using svn which perfectly fits my use case and does everything I need it to do. As I say, it stays out of my way and doesn't take any of my time up.
You seem to assume everyone uses revision control in exactly the same way and that everyone has exactly the same needs/pain points/etc
Or, I could just continue using svn which perfectly fits my use case and does everything I need it to do. As I say, it stays out of my way and doesn't take any of my time up.
You seem to assume everyone uses revision control in exactly the same way and that everyone has exactly the same needs/pain points/etc
doesn't take any of my time up
So I assume your SVN server is on your local network which never goes down, you never work in another location, and your repository is tiny.
So I assume your SVN server is on your local network which never goes down, you never work in another location, and your repository is tiny.
Hear hear!
Versioning is about 1/10th of software engineering, and it's about 1/1000th of running a successful startup.
I wonder how many companies managed to survive in the bad old dark ages before we had git? </sarcasm>
This incessant cheerleading is obnoxious. Source control is simply not that much of a time sink (or shouldn't be) to warrant all this attention.
Work on making something people want, folks. Stop getting all wrapped up around the axle about some nifty new wizzbang tool.
Versioning is about 1/10th of software engineering, and it's about 1/1000th of running a successful startup.
I wonder how many companies managed to survive in the bad old dark ages before we had git? </sarcasm>
This incessant cheerleading is obnoxious. Source control is simply not that much of a time sink (or shouldn't be) to warrant all this attention.
Work on making something people want, folks. Stop getting all wrapped up around the axle about some nifty new wizzbang tool.
> Wish people would quit with the "Tool X is always better than Tool Y".
Most of the time, I would agree with you. In this case, DVCS is a superset of VCS, so it is _always_ better.
Most of the time, I would agree with you. In this case, DVCS is a superset of VCS, so it is _always_ better.
A superset is not always better.
Consider domain-specific languages vs. general-purpose languages. You need to weigh the benefits of increased power with the drawbacks of additional complexity.
Consider domain-specific languages vs. general-purpose languages. You need to weigh the benefits of increased power with the drawbacks of additional complexity.
Ease of use is important, we certainly agree on that. But "git clone url" vs "svn co url" and "git commit -a" vs "svn commit" isn't significantly more complex.
Centralized VCSes can lock files. DVCSes cannot. Ergo, DVCSes are not a superset of centralized VCSes.
Couldn't the upstream repository just not accept changes to that file? I'm sure this could just be managed by some kind of commit hook.
Interesting. I hadn't considered that possibility. I'm more familiar with hg than with git, but from what I gathered in #mercurial, it should be possible to write a combined extension + a commit hook that:
* allows people with appropriate permissions to lock and unlock files
* sets locked files to read-only on pull from the canonical repository, so that users are warned beforehand that the files are locked
* rejects commits that modify locked files except for by the person that holds the key
There are a bunch of issues that need to be worked out, but I think the problem is tractable. Nice, thanks for the idea!
* allows people with appropriate permissions to lock and unlock files
* sets locked files to read-only on pull from the canonical repository, so that users are warned beforehand that the files are locked
* rejects commits that modify locked files except for by the person that holds the key
There are a bunch of issues that need to be worked out, but I think the problem is tractable. Nice, thanks for the idea!
Not until there's an SCC provider for integration with Visual Studio. You're not going to get many of the coders in my company using the command line (or third party software) to check code in/out.
That's a shame. The shell is great, once you know how to use it.
Sadly, that's the problem - it's yet another thing to learn, on top of multiple sets of infrastructure, IDEs, etc.
In interest of a full comparison does anyone have a link to an article discussing the reverse topic of why subversion is better than git? Does such an article even exist or is git that much better than subversion?
I've never seen such an article and in my own personal opinion, I don't see how such an argument could be made. I'm not a fan of Git in particular, but I love the "distributed" in DVCS. I use BZR on a daily basis and have never once found anything I missed from the days all of our projects were in SVN. You can use most of the DVCS tools just like SVN if you want (checkout, update, checkin), or go all out distributed with branches, merges, pushes, pulls, etc.
I guess SVN gives you real Trac support. :-) There are Git, BZR, etc plugins for Trac, but they all feel very hacked in and incomplete to me. I love BZR because it gets you launchpad.net (and it's got some stellar Py-bindings). I know Git has github, but I don't care for it either as a real project management suite.
EDIT: (Note: My opinions are from an open source developer perspective.)
I guess SVN gives you real Trac support. :-) There are Git, BZR, etc plugins for Trac, but they all feel very hacked in and incomplete to me. I love BZR because it gets you launchpad.net (and it's got some stellar Py-bindings). I know Git has github, but I don't care for it either as a real project management suite.
EDIT: (Note: My opinions are from an open source developer perspective.)
You should checkout http://www.redmine.org/. Not only does it have real git support, but I much prefer it to Trac.
Here's one take, though it's not wildly convincing:
http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/W...
My job in the past was to evaluate source control systems for different organizations and what made the most sense. While I think Git and Mercurial are great for open source pieces, I'd pretty much never recommend Git inside of a large organization just yet. Perhaps never given how much visibility and control most companies want on their internal development flow. Checking in code to local repositories on any large scale isn't something most companies are big fans of.
Overall, Perforce is probably my most recommended for companies, though it has its downsides. Subversion with their improvements to branching should be getting more props these days, though. ClearCase is preferred by a lot of process-focused software companies (government contractors, etc).
What I think traditional centralized systems need is a better story for local repos or at least private branches. It needs to feel natural and built-in so that smaller pieces of work can be handled quickly without necessarily shipping them to team branches (or main). It's all doable now but the emphasis and infrastructure should encourage incremental changes in isolation which Git and Mercurial do a great job of. This feature isn't one major organizations need as an essential, but developers sure know the importance of it.
http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/W...
My job in the past was to evaluate source control systems for different organizations and what made the most sense. While I think Git and Mercurial are great for open source pieces, I'd pretty much never recommend Git inside of a large organization just yet. Perhaps never given how much visibility and control most companies want on their internal development flow. Checking in code to local repositories on any large scale isn't something most companies are big fans of.
Overall, Perforce is probably my most recommended for companies, though it has its downsides. Subversion with their improvements to branching should be getting more props these days, though. ClearCase is preferred by a lot of process-focused software companies (government contractors, etc).
What I think traditional centralized systems need is a better story for local repos or at least private branches. It needs to feel natural and built-in so that smaller pieces of work can be handled quickly without necessarily shipping them to team branches (or main). It's all doable now but the emphasis and infrastructure should encourage incremental changes in isolation which Git and Mercurial do a great job of. This feature isn't one major organizations need as an essential, but developers sure know the importance of it.
The big failing of DVCSen is that you lose the ability to do fine-grained ACLs on code. For example, if a company wants to restrict access to certain parts of their codebase (eg, megacorp brings in contractors, they should see only the one tiny part of the code they work on), you can do that in svn, whereas with git you can't give them access to part of a repository. Heck, you can even integrate your ACLs with Active Directory if you have enough LDAP/Apache config fu.
Also, it makes pointy-hair types more comfortable to have a central server where everything is obviously canonical.
I don't think DVCS will ever fully supplant centralized systems (including Subversion, Perforce, and whatever else people use these days) in the corporate world.
Also, it makes pointy-hair types more comfortable to have a central server where everything is obviously canonical.
I don't think DVCS will ever fully supplant centralized systems (including Subversion, Perforce, and whatever else people use these days) in the corporate world.
Is it possible to pull out a portion of a project and then serve that as the canonical branch for the contractors? After the contractors git to their hearts content, could someone blessed to commit to a "master" then push only those changes or is that something that will not work?
I haven't used much git but they tout it as a very flexible system so I am wondering if it is flexible enough to accommodate this type of constrained work flow.
I haven't used much git but they tout it as a very flexible system so I am wondering if it is flexible enough to accommodate this type of constrained work flow.
Mercurial and Git currently have no support for checking out part of the tree. It's been designed a couple of times for Mercurial, but never implemented.
(Git people: please correct me if that's changed since I looked last, a cursory Google search indicates this problem is unsolved as yet)
(Git people: please correct me if that's changed since I looked last, a cursory Google search indicates this problem is unsolved as yet)
You can do ACL with a DVCS by way of a pre-receive hook. It's just a matter of time before tools make this dead-simple.
That's commit-time ACLs. I'm talking about read ACLs. Some companies aren't comfortable with giving people total access to code, even code that logically would sit in a single git repository.
SVN has HTTP auth. no SSH key BS. Until Git has this you can forget about adoption for most corporate dev.
It's just a linkbait headline. Use whatever fits your usecase the best.
For me to switch from svn to git, I need to be experiencing pain using svn. I don't feel any pain :/
Of course if I'm working on a project in the future that looks like git may help, I'll look at git and see if it'd be more appropriate than svn...
Wish people would quit with the "Tool X is always better than Tool Y".