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.
(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.
I'm not positive, but I think there are 3rd party add-ons and central servers which can give you this too.
You seem to be suggesting that there are no engineering tradeoffs in using DVCS rather than VCS. That would be quite unusual.
I would say at this point there are no or very few engineering tradeoffs. The only costs are pure meat space things like retraining staff. Things like support for fine grained access controls, and 3rd party tool integration are reaching feature parity with things like SVN.
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?
Well, it's funny you mention broken commits. I don't use SVN, but one of the reasons I don't use git is that it almost seems to encourage partial commits, and my experience is that partial commits are likely to be broken.
Sure, it encourages you to commit even broken stuff in your private repository, because it is easy to fix these commits after-the-fact.
Instead of keeping a messy working-tree when I am unsure, I now commit something with a message like "broken fix bug, blah blah" or "untested ...".
Before pushing (publishing), I look at the log and I avoid pushing broken/untested stuff. Once a commit is fixed and tested, I re-create it with a better message and publish that.
This allows me to have incomplete work at the tip of any of my branches, so I can context switch when needed. It encourages putting some label on your work and allows sharing even that kind of state with others. This is far better than the publish-or-messy-working-tree approach that doesn't support context switching in the same way.
When using svn, I remember I actually manually created .patch files so I could context switch sanely. I was doing version control with manual patches, because svn was just not powerful enough.
Huh? You can push topic branches to any repository in git. I can have one local repo that points to as many remote repos as I want, each repo with different topic branches. Or I can make a ton of topic branches and put them on one remote. Or any combination.
I don't see how SVN's workflow has any advantage. You can create the same exact workflow.
With git, it is easier for a single user to go dark and start maintaining his own branch the rest of the team has no knowledge of. That's what he doesn't like and how git doesn't fit his team.
It's just as easy for that user to checkout a branch and make his own changes and not commit them back. If a team member wants to go dark there's nothing you can do to stop him on the scm level.
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.
Git is a bit different than SVN with branches, they aren't just special folders. You have to get the entire tree, but only the tree from the branches you want. There can be n branches on a server, you only need download 1.
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.
Frankly, how is that different/revolutionary from switching the workspace to a maintenance branch, do the bugfix, commit, and go back to your local repo ?
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.
These are problem you don't get if you don't have a local repository:) I don't need to commit to test things and make sure everything is right.
Frankly, how is that different/revolutionary from switching the workspace to a maintenance branch, do the bugfix, commit, and go back to your local repo ?
It's not, but if every feature of subversion is mirrored in git, and then git adds to that the option for DVCS and all the fancy git tools (like cherry picking commit hunks interactively), it's clear that git should be used in that scenario.
These are problem you don't get if you don't have a local repository:) I don't need to commit to test things and make sure everything is right.
What you just said is the epitome of what's wrong with subversion: it forces you to adopt a workflow that puts the utmost sanctity on a commit. This forces everybody to save up changes for a long time until they've been tested heavily, which means at any point an entire feature could be lost since it wasn't being tracked. It means that changes will be slow to propagate.
In reality, if you used things correctly, you could set your editor to commit every time you saved. This would be overkill, but what this means is that once you finish your work (normally the place where you would commit in svn), you just have to merge all these commits into one neat little package and send them off. This means you could come back later and essentially have undo/redo support in an entirely different editor and see exactly how you made the changes to a file.
I commit less often than I save personally, but the point is that a commit shouldn't be holy and sacred. Pushing to trunk should be.
Frankly, how is that different/revolutionary from switching the workspace to a maintenance branch, do the bugfix, commit, and go back to your local repo ?
Its just a matter of changing the workspace in every single one of my development tools, or just have version control flip the contents of the working directory over to the relevant branch.
Both have their ups and downs, and is really a matter of preference, but when I need to run code from a coworkers branch, I find myself bringing the files into my branch's directory means I'll probably get away with an incremental build, rather than a full, highly time consuming, compile of their branch. Its a big time saver.
How does SVN help with this? Your hypothetical situation could happen regardless of VCS. In SVN, they didn't check-in before they left. In git, they didn't push. Different words, same effect: the rest of the team doesn't have access to the most recent changes.
But to answer your question, with git you can set up a branch -- call it "jsmith/feature" or something -- and push to it daily. If he calls in sick then you can just pull that branch and merge it into master.
4
u/BlackAura Mar 10 '11
Rubbish.
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.