From: Brian Mitchell Date: 2007-03-15T10:49:44+09:00 Subject: Re: Why SVN? On 3/14/07, Austin Ziegler wrote: > On 3/14/07, Brian Mitchell wrote: > > I can't resist replying to this troll. I call FUD on the "distributed > > version control systems without much proven technology behind them" > > claim until we get details. I'd really like to hear why you think you > > have a winner just because something is different. It's obvious you > > think you have a great reason to feel strongly about using Subversion. > > I think it is only fair that you share why if you plan on telling > > people such absolutes. So please, enlighten me. > > Careful who you call troll. You'll find your assumption comes back to bite you. I knew I could count on a good reply. I know you are a good debater. I need not bring up the topic of benchmarking with you for example. ;-) > Technology is proven by (1) wide use and (2) long experience. CVS and > Subversion at this point are proven technologies that are widely > adopted. That doesn't necessarily make them best of class, but it > means that people know what to expect from them. Some of that will > include bugs, but the core technology is proven. There are billions of > lines of code in CVS and Subversion systems being protected and > managed right now. Yes. Though there a millions of lines of code written in languages a lot here would consider primitive. There are also millions of more lines of code being written with no version control as well (I would guess, though there is no denying that this number is larger than it should be). I think I will agree that the wide spread use is important, but I don't think adoption is the only metric to look at. > Subversion has meaningfully improved upon CVS and has improved the > state of the art for open source centralized source management. I > wouldn't dare call it best of class, but I would use it for any open > source project because it (1) has a lower barrier of entry across > platforms and (2) works in ways that people expect it to. I'm less > convinced that I'd use it for professional software development after > my experience with Perforce at my current job. Perforce is an > absolutely amazing piece of software that gives many of the supposed > benefits of distributed development platforms (lightweight branches, > patch cherry picking), and with p4proxy, you get better distributed > development (although *not* apparently disconnected distributed > development). No argument here. There are a lot of projects that thrive off of easy entry. I think Ruby on Rails is an excellent example that many in this community have been influenced by. I hear more and more people taking up Subversion because of how pleasantly it works with the rails development environment. Professionally, I use subversion, though my team is looking to migrate to something that does a better job at branch management and merging. The verdict hasn't been given yet, but it will likely also be distributed. Your review (and the reviews of others in this community) might make an impact. I will likely give Perforce another shot (though I know the team I work with is much more likely to want something open source). The important thing here is, for those of us who can afford to learn a new tool (effort required here is usually exaggerated), the history of a tool is a smaller barrier to entry (provided it works correctly). I am much more likely to pick up an alternative in some of my projects because of this. > There's so many different distributed systems right now that work > differently from each other and have forked because of differences in > opinion on how the programs should work that it's nearly impossible to > choose one reliably. Many of them suffer from an extreme anti-Windows > bias and very few of them (if any!) have GUI support for visualizing > changes over time. I personally find disconnected distributed version > control systems to be very fragile in that entire branches can go away > because a middle version is purposefully or accidentally deleted. > People say that distributed systems have cheap branching, but I find > that very hard to believe, since (at least in the ones that I've > tried, and I have a hard time imagining how others would differ) the > branches are physical copies in a different location. That's cheap for > the making, yes, but your total storage cost goes up (since none of > the advantages of having a single repository can be found) and it then > becomes possible to *lose* branches from your repository (cf fragility > above). I have to admit that none of the people I work with write their code in a Windows environment. In fact, as a team, we officially don't support it. The only windows environments we have left are for testing some of the web applications in Internet Explorer. This would probably count as a bit of context I guess. I will note that I've never had a branch problem, though I guess it depends on how you manage your code. I usually have very little that could be lost if I, for some reason, wanted to rm -rf a working copy. I think most of this is helped by following a set of conventions for each tool. There is a reason subversion makes use of the trunk-tag-branch structure... and there are similar reasons that people work certain ways with other tools. I usually have a couple places I put code depending on the project type. In many cases, I setup my environment with a central repository that represents something like a trunk. Real development is done outside of the trunk but synced in functional groups. Locally, small changes are recorded quite often (this accentuates the power of cherry picking in an interactive system). It seems that this duplication gives it the same "relative" reliability that a standard Subversion setup would have (detached code repo being one if you have multiple machines). For cheap branches... I'm not sure either. It has always boggled my mind why people are so upset when two files have to be duplicated. One system that really does cheap branching well is git. Only a single file with a few characters is created for each branch (initially, changes are added of course). I'd love to hear from others who know more about this. > There's a lot of things to like about the *ideas* of DDSCM, but in the > real world, I find that I'm rarely disconnected from the 'net long > enough to care about the fact that I'm using a centralised management > system. True enough. I like some of the ideas because I am one of those people who has experienced significant offline development. Maybe it conditioned me to where I am now. > So no, not a troll. Well informed using shorthands that should have > been pretty easy to determine if you weren't blinkered by the > proponents of DDSCM in the first place. Yes. I know I lean far to the DDSCM side of things and I don't intend to hide it. I think the quality of this reply made up for the originally open claims. Though, I would like to ask, out of all the problems you mention, none of them really give a benchmark that could be used to note if a DDSCM would be ready under your definitions, are there any specific things that could be fixed or done to make your trust in a DDSCM system more likely? Or is DDSCM, for some reason, mutually exclusive with what you get out of your current SCM usage? Thanks, Brian.