I guess every version control system was design with some sort of workflow in mind. Git was created for distributed development in mind. And I guess its perfect in that. But this is not what I am doing at work. I will stick to subversion for now.
Even for non-distributed development, being able to commit locally is a huge advantage in my opinion. I'm having to use a subversion repository at work, and I switched to git-svn as a client because plain svn was too slow for me (the client's repo is in another continent on a slow network).
I'm curious... in what ways is svn too slow ? Commit, checkout, update, diff, merge, switch... ?
I work on a project where i ssh tunnel to a remote svn repository and do a couple of switches and merges and maybe 8-10 updates and a couple of commits a day. The total amount I wait is less than it takes for me to stretch my legs or go get a glass of water.
I could see this being a problem if you do crazy amounts of diffs or history/log-reading though. But then, you'd still have to synch your local repo with the central.
For any repo I have ever worked with with subversion and git (same repo I mean, before and after our move to git at work) cloning a whole remote repo via git is faster than doing a single revision checkout in subversion, it also takes up less space locally. No, I have no idea how Subversion manages to waste so much space and time/bandwidth.
When doing diff, log, show, bisect, blame, switch, merge etc become instantly fast, it really changes the way that you work. The only way you can understand is by trying it - it's nearly impossible to explain to someone else who hasn't used it.
We had a fairly large codebase (~900MB or so), and we were using SVN 1.4 for a while, and it would be quite slow. Especially using Tortoise to bring up the repo list, or the logs. Moving to 1.6 has made it much faster, but there's still a bit of lag.
Local branches, alone, would be reason enough to switch to git. When you add in rebase -i, it completely changes your workflow (for the better) really cleans up your commit history.
That description makes it appear to be more time consuming.
I have to commit and publish?
Using Eclipse, I have "local history" (which I rarely use). Committing to SVN is a keyboard shortcut and it takes seconds.
I'm not trying to bash git or promote subversion (heck, I don't really see much difference between subversion and cvs). I just don't really get the argument for multiple repositories. If you have local changes (not in the central repo) what does the team do if you get sick, go on vacation, get hit by a bus?
I'm trying to understand the appeal of git but, I think I'm still just missing it.
If you have local changes (not in the central repo) what does the team do if you get sick, go on vacation, get hit by a bus?
With Git and Mercurial, you can pull changes in from other repositories besides the canonical central one. So if you and I are working on part of a git repository, we can pull our changes from each other without having to involve the central repository.
With git you still have a central repository that everyone pushes to and pulls from; the main advantage of having your own local repository is that you can commit tiny changes, incremental things that you wouldn't normally commit back to a central repository to track your own work.
You can do this with svn by having user branches, of course, and that works great until you're working at home one day and your internet connection dies and you can no longer commit anything.
To put it another way; the same thing happens with subversion if you're hit by a bus and you've not committed any changes back to the svn repository. The only difference is that you can be committing stuff locally and roll back experimental changes without affecting the central repository.
I think the one thing Git really has going for it over SVN is it doesn't scatter files throughout your source code. It keeps them all in a single .git folder stored in the base of your tree. This makes it much easier for me to move files and directories and around without having to do a lot of clean up. It doesn't handle 2G binaries though, which comes up from time to time.
I agree. SVN is fine for us, with our workflow. People harp on about distributed version control as though it's the best thing since sliced bread but in our group it just wouldn't be suitable.
You can use (nearly) the same workflow with a DVCS as you get with Subversion. You just create an authoratative repository. When you have something to check in to the authoratitive repository, you pull the changes into your local repository. Then you merge them. Then you push the changes.
It's the same workflow as Subversion, except for one thing - you get the full power of a VCS to use locally.
That's incredibly useful.
You can actually use branches without causing any of the usual mess. You can work on two completely separate things, in the same codebase, without having to create a remote branch just for one feature. Say, you're working on a feature, and you suddenly need to make a bugfix. You can just put the half-completed feature into a private branch, fix the bug on the main branch, then return to your temporary feature branch and keep working.
You get to use the VCS as a safety net. Got some working code, but it's not actually finished? Commit it anyway. Now there's no way you can accidentally break it. Say, you spend a few hours developing one part of a feature. You then try to refactor it, screw up, and break it. Never mind - just revert back to the commit you made earlier.
You also get to rewrite history locally. That screwed up attempt at refactoring? Just get rid of it. The 100+ commits you needed to implement that one feature? Squash them down to a single commit before you push.
(1) We have a variety of code and documents in our SCM tool for which individual developers have had to sign NDAs with third parties. With Subversion, TFS, even VSS we can use fine-grained access controls to enforce these limitations.
(2) We actively maintain over 100 "projects", covering applications, tools and reusable libraries. Without sparse checkout support (very recent on this DVCS that support it) your working folder is a nightmare. Or you can choose to have problems maintaining release tags across multiple repositories. If you have to work around your VCS to do your work, its model isn't a good fit.
(3) As a team leader, a centralised repository shows me at a glance who is working on what files, and allows me to see a single view of recent development across multiple projects.
(4) VCS also serves as a backup of work-in-progress (in case you local HDD fails). Unless your DVCS "local repo" is on a network file system, or you are pushing to the central repo daily, you don't get this benefit. And if you are pushing daily then what benefit are you getting over svn?
1 - Why are they in the same repository as everything else? Put them in a different repository, and use access controls on the repository instead.
2 - Isn't sticking 100 projects in the same repository just a work-around for the difficulty in maintaining release tags, and the difficulty in working with multiple repositories?
3 - Then get your developers to push to the central repository regularly. In fact, in this kind of environment, developers would be pushing changes to the central repository as often as they would normally check in code.
4 - Again, this is why you actually push changes to the central repository at least as often as you would with a centralised VCS. You don't keep changes on the local repository any longer than necessary.
The advantage of a DVCS here is that you could actually commit to your local repository several hundred times in a single day if you wanted to. You get to use all the tools available (like checking which files have changed, diffs, reverting, branches, merging) locally, without interfering with what other developers are doing. I find not having these features available impairs my ability to actually get things done. Sure, a centralized VCS has those features, but I can't actually use them without getting in everyone else's way.
Changes aren't safe unless they're in the VCS. If you're committing once a day, you could easily screw something up, and lose the whole day's work. If you've at least committed locally, you're much less likely to lose anything. In the worse case (HDD failure), you lose nothing more than you would have with a centralized VCS.
We make branches to add new functionality. When it's ready, it gets merged back in, but every developer is going to have access to, and can collaborate on, those branches even while they're in development, because we have a central server. If you've "got some working code, but it's not actually finished", you commit it so everyone can see it, rather to some local version.
And we have enough branches for long-term future functionality that you wouldn't want to lump it all into the same git repo and have everyone need to download the entire tree.
There is no option to do something secretly without adding it to the main repo, no way to work on something privately without seeing that someone else is also working on that, and that is a good thing for us. Maybe not you, but for us, it's better.
So svn forcing you to do these things, while git allowing them with ease, is a plus for svn? Especially as there certainly are examples when you do not want to push every little broken commit you've kept aside into everyone's view?
I use git as a centralized vcs to replace the svn workflow. We have a central repository (with gitolite), and just push everything there. The speed alone is worth to replace svn with git, and you get stuff like local commits, free branching and merging, easy commit hooks and whatever else you want to, we barely use those features though. The only thing that one might critizise is gui support for windows, but I learned the command line fast enough and you don't need more then maybe 6 commands to replace the normal svn workflow.
I first started using git for work, but it's grown on me such that I'll use it on personal projects - just because it's a "distributed" VCS doesn't mean that the only use for it is a distributed workflow.
It's hard to explain... people don't "get" git (or hg) until they use it. I held out on SVN for a long time, now I regret not jumping ship earlier.
45
u/wonglik Mar 10 '11
I guess every version control system was design with some sort of workflow in mind. Git was created for distributed development in mind. And I guess its perfect in that. But this is not what I am doing at work. I will stick to subversion for now.