Does any one have experience using hosted svn? Are they reliable?

We used http://www.svnrepository.com/ before we migrated to our own servers. No downtime, but it was a little slow.

But, if you have any choice right now, use a DVCS!!! (like bzr).

I cannot stress how much better our workflow is. We’re night and day more productive. I cannot stress enough how much better it is not to be using SVN. Seriously.

Seriously.

Seriously.

On a team of five developers how would DVCS make us more productive?

Isn’t fluther run by a team of three men?

Three handsome men.

My point is that if DVCS made three people more productive, would it not make five people even more productive?

In what ways has it made you more productive? I don’t mind using cvs or svn… what is so much better about a dvcs?

According to wikipedia, a dvcs “Will often require many more merge conflict resolution by hand efforts.”

That alone sounds like a deal-breaker. Manual merge conflict resolution can be painful.

Oh wiki. You lie! We actually have merge problems much less than when we used SVN.

Here’s what’s great about DVCS. Our workflow is actually very similar to our SVN workflow, with a definitive master branch that we release from.

Why is it so much better? Because we can release features a lot faster. Why? We have more granular checkins and we have better code isolation.

Here’s how it’s set up, and why we’re much more agile now:

We have a central ‘trunk’ branch from which we deploy. Each developer has a copy of that master branch on their own machine, bound in lockstep to the master branch (a checkout in bzr terms)—meaning that in order to check in a change to the master branch, you need to be up-to-date (exactly the same as SVN).

Whenever one of us works on a new feature (no matter how small!), we simply branch a copy of the tree (locally), check into it until it’s stable, then merge back into our local copy. We run tests, then upload to the master tree.

Yippee doo, you say, doesn’t seem like a big thing. But when we used SVN, say I found a bug or a high priority fix. If i was in the middle of a new feature, oh, crap, I was out of luck. I could create an SVN branch, but that took some time and work and was a pain to merge back into trunk.

With bzr, I can simply make a quick branch, work on the feature, then merge back into trunk. Done. I don’t have to worry about cleaning up my local code.

Beyond, that, though, is the benefit of having a local checkout. Why is that great? Because you don’t have to wait until things are stable to do a checkin. Because my local checkins don’t affect other developers, I have an incentive to do a bunch of checkins—and I feel much better about developing because I get that positive reinforcement of small steps. If you’re using SVN, you end up waiting to checkin because you don’t want to break trunk.

I had no idea how much of a benefit it would be when we switched—I thought it would be a neat experiment. But after using bzr, I will never ever ever ever go back to SVN.

Branching and merging in svn is a pain! I’m a fan of git (and using Github). It’s much better than svn. It sounds fairly similar to DVCS, from what andrew’s saying.

Thanks for the thoughtful answer Andrew. It sounds like the big advantage over using svn with a branch for each developer is that changes to the trunk are merged to the branches automatically (or easier, at least). Is that right?

@damien: DVCS is just a distributed VCS system—like git, mercurial, bazaar, etc. We chose bazaar because it has built-in support for svn-like workflows, it’s written in python, and it has fantastic merge tools.

@jasongarret: Partially. Changes to trunk aren’t necessarily pushed out to branches automatically (unless you want them). The biggest boost you get is that instead of having one branch per developer, each developer can have a branch for each new feature.

So andrew can be working on feature A, while ben is working on feature B, and if ben needs help, he can share his branch really easily without fouling up feature A. And while andrew is working on feaure A, if there’s a bugfix that needs to go out pronto, he can just create a quickie little branch, push out the bugfix, then go back to working on his (partially-completed) feature A.

There are a lot of other great benefits (like the fact that checkins are really fast) and the fact that you can still work while you’re on a plane, but that’s the basic gist.