+972 52-548-6969
I don't like distributed source control
Let us see how much of a furor that will cause :-)
The reasons that I don't like distributed source control systems have nothing to do with technical reasons, and everything to do with how they are used and promoted.
The main reason that I don't like them is that they encourage isolated work. I don't want anyone in my project to just go off and work on their own for a few weeks, then come back with a huge changeset that now needs to be merged. The way DVCS are promoted, this is a core scenarios, "no one have to see your mistakes".
I completely disagree. I want to see everyone's mistake, and I want them to see mine. There is little to learn from successes, and much to learn from failures. Far worse, I want to be able to peak into other people work, so I can give my input on it, even if it is just "wow, nice", or "yuck, sucks!"
The main advantage of DVCS is speed, trying to browse the repository when you have the entire thing on your HD is lightning fast, compared to doing the same with a remote repository. I tend to use SVK now, but I use it strictly as a local cache, and nothing more.
And that is why I don't like DVCS, I don't want people to work in isolation.
Comments
Distributed Source Control doesn't mean people have to work in isolation. It just saves time when someone makes checks in code that doesn't compile. But I guess no one can stops one's stupidity. I do love the speed of DVCS. It's blazing fast!!!
DVCS don't force you to work isolated, you can also use them in a centralized way and going distributed when needed. Or you can use it just the same way you use SVK. It is not the job of a (D)VCS to avoid bad practices from your peers.
Oh, and they seem to be much better at merging than SVN. I had heard how bad it was for a long time, but I didn't really know until I have tried it myself. Just that reason alone is enough for me to switch, the only reason I haven't done it yet is that I haven't found a tortoise${VCS} mature enough for Windows that my folks can use.
Linux Torvalds has very nice presentation where he bashes all non-distributed source control systems :)
http://www.youtube.com/watch?v=4XpnKHJAok8
Amen. I have seen the same thing - the concept that you can work in isolation, only pushing out when necessary. I know that you aren't saying that it is /impossible/ to work in a non-isolated fashion. But it makes it harder to push that when being able to be isolated is touted as a core feature.
Only pushing out when necessary does not == work in isolation.
I guess I haven't seen anything that says go take the code and hide in a basement and never share it with anyone until it's perfect.
The concept of being able to do frequent commits without 'sharing' is more akin to promotion than isolation.
I have one project still living in VSS, and on that project there is s 'special' tool developers use to put a special label on some code that says this code is ready for a QA build.
Replicating that same behaviour is ugly and hacky in subversion, but in a DVCS the notion is pretty much baked in.
Surely you don't need distributed source code management for this, just decent branch management - on one project I had one task involving around 1500 stored procedures that stayed on a branch for 3 months until it was full finished.
The ability to merge from the trunk to your branch is vital though.
@Paul yes, and the DVCS get merging right, subversion is great at branching, terrible at merging.
In subversion when I merge I lose all that history of what happened in the branch. To me that means it doesn't work.
+1 to paul hatcher, you only need a really good branch management and of course the capability to work disconnected, it seems that svn 1.5 would bring us a good branch management, so I guess we would be really happy with it :D
+1 to paul hatcher, you only need a really good branch management and of course the capability to work disconnected, it seems that svn 1.5 would bring us a good branch management, so I guess we would be really happy with it :D
@chris, btw, have you heard about svnmerge? it would help you a little with branching in svn 1.4
@chris, btw, have you heard about svnmerge? it would help you a little with branching in svn 1.4
I'm not quite as worried about isolation, since that's a bad habit someone could have on a svn team as well. Although I guess you could argue between svn and git you could fall into good or bad habits out of default.
A similar concern I had was about process, though it could be worrying about a problem before you have it. In a production environment of a public property would you have any mixup in the day-to-day change management. Either out to the world, or keeping your own workstation current. It would probably only take one or two events to be an killer anecdotally.
Aside - I think a lot of the design of the git workflow comes from the psychology of Linus himself. I'm sure he'd agree. Then call me stupid. :)
I agree with your arguments, especially given the marketing scenario you mentioned. That slogan sucks, and isn't what DVCS is about to me. The problem with marketing DVCS that way is, who has the official build? Why does one person own the official build?
I think products like GitHub.com show that DVCS can be hugely popular but still be treated as semi-centralized. Also, GitHub has made the process of submitting patches amazingly simple with their forking features. DVCS tools like Git have much better branching and merging features, and having complete repository access when offline is a big plus. That's why I prefer DVCS.
As has already been stated, most of the perceived deficiencies of centralized SC can be remedied by good branch and merge support. That video of Linus just shows such ignorance of that fact. He talks to a room full of perforce users and tells them perforce is crap and only GIT is good, and then justifies it all by tearing into short comings of SVN as inherent short comings of centralized SC.
Been using svn and perforce for years and every complaint i've come across with svn is alleviated by perforce. Yes, i am a perfoce fanboy, but I became one through very pragmatic experiences.
At my current gig, we use perforce with cruise control and we get commit emails. Even when i'm off on a branch for a couple of days on a longer task, having that commit email feedback is invaluable, because at least i'm in the loop as to what I might run into once i synch up with main or merge back.
I am not completely agreeing to Ayende because using DVCS depends on the kind of application you're working on. If the work is divided among the developers by considering the distributed nature of source control system then "isolate" development will not be a pain. And I agree with Arne about the commit email feedback. It helps a lot about what i am doing wrong.
Sorry for being a late commenter, but I feel need to reply since I find this post and some of the comments a bit uninformed. Yes, uninformed because there’s nothing about a DVCS that encourages you to work isolated; a DVCS only enables you to commit and branch locally, if or rather when you need to: working off-site with no access to the central server, on a business trip/plane, doing personal experiments you want to keep for reference, and for many other reasons.
Using a centralized repository is a common setup, and you can of course hook it up with a build server (“the official build”) for continuous integration. Bazaar has an overview of different suggested and supported workflows:
http://bazaar-vcs.org/Workflows
I think of DVCS as the next evolution in source control. It’s the classic VCS with much added goodness. The branch support is strong (Subversion’s upcoming branch support in 1.5 will be far from good), it enables more workflow models, and it’s generally faster. The tooling support is not fully there yet, but it’s being worked on.
Dear reader, do yourself a favor and learn about it by actually trying it out. http://git.or.cz/ is still a bit hardcore, so I’d suggest trying http://bazaar-vcs.org/ or http://www.selenic.com/mercurial/.
Comment preview