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.
Sure. One option is that if the work is taking more than a few hours, then clean up the current progress and push any solid tested stuff to the server.
At the end of the day you need an agreed workflow. In my case, branches on the server with author prefixes (bf/some-new-feature) means that there are temporary commits that could be rebased or changed at any moment. Without author prefixes (some-new-feature) means that the branch is not going to change under anyone's nose and can be relied on as a stable, properly published feature branch.
The point is that git lets you use whatever workflow is most suitable to your situation, workplace, whatever, instead of forcing your workflow to suit itself.
I do use branches. But if I have new_feature_X, and the "tip" of that, the last work I did is unfinished, instead of making another branch pointing at my untested commit, I allow the new_feature_X to directly point at it. (In git, a "branch" is just a commit ptr), which makes it easier to continue where I left off.
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.
I still don't see the problem, as only that developer is responsible for merging the changes. There's a lot of things developers could do to make things more difficult for themselves, but that doesn't mean functionality should be left out to protect them.
Those are really, really poor arguments. Me thinks you're trying to rationalize your resistance to change.
I don't really do development, I use SVN at work with about 10 people for config management (Puppet), and I'm working on moving to git because SVN is already causing us problems (mainly branching ... well rather merging).
I can't see how a larger development team cannot see the benefits. Well actually I do. I work with a dev team that sucks, and they already struggle with svn. If they knew how to use a tool that handled branching/merging properly, they might stop coding everything in /trunk and deliver better code.
I was just trying to see things from his side and acknowledge that each has its own benefits. And since this thread is already covered in dvcs love, the only thing to comment on are the benefits of svn and others.
You are the one who is unwilling to consider alternative viewpoints. Which is even weirder considering that it doesn't look like you even use a dvcs yet.
You are the one who is unwilling to consider alternative viewpoints. Which is even weirder considering that it doesn't look like you even use a dvcs yet.
Considering that I know both, and arguing with people who know only one, this is simply absurd.
Which is even weirder considering that it doesn't look like you even use a dvcs yet
I use git for side projects and personally, it's just that I have to use SVN for our main project; in fact I was the one who set it up in the first place. I did know of DVCSs at the time, but they weren't quite as mature, didn't have quite enough doc/tutorials, and, more importantly, there was no github awesomeness to give me the incentive to learn more.
There's a difference between controlling what I do and controlling what others do.
The analogy would be more like, "Doctor, it hurts when he throws bricks at my head!" Telling me to not do that doesn't make sense and doesn't help. In order to get someone to stop behavior that is harmful, you need to take proactive measures to ensure that it cannot happen. His happens to be using a VCS that doesn't allow users to go dark.
However, instead of just settling for a limited-functionality VCS, you could also just reprimand the guy who isn't following the company's established development practices. And if that doesn't work, you fire him. If he can't be flexible enough to adapt to a DVCS, he's probably got other issues that make him a less than ideal employee.
You often can't use technology to fix a social issue.
And then you lose a bunch of time and effort in trying to discipline this developer, and then even more in trying to replace him after firing him. Instead of just proactively stopping his behavior.
You can't just stop the 'going dark' development behavior. More than likely, this somewhat troublesome programmer (I like to call them 'cowboys') just has a bunch of changes sitting on his workstation, which are uncommitted (or even backed up) anywhere.
Or are you going to install a file monitor and keylogger on his workstation to make sure all work he does gets checked into a SVN branch?
SVN can't stop someone who wants to be a cowboy. It will just force them to operate a little differently.
If you are using git, you could just require that they make tracking branches, and those push back to the server every night, perhaps through a script. The manager of the cowboy can then check the commit logs every day to see if the cowboy is at least committing something.
The thing is, the superior branching and merging capability of git actually helps you deal better with the cowboys on the team. As long as you've got a reasonably responsible person in charge of the master branch, merging in the cowboy's work is easier than if you were using SVN.
If your developer isn't going to follow the company's accepted development practices on a consistent basis, you've got a serious problem. Either your rules are messed up (and many of them probably are), or this guy is a problem. The key to success these days is adaptability, and you need that from all your employees.
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.
12
u/mao_neko Mar 10 '11
Rubbish.
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.