From: Austin Ziegler Date: 2007-03-15T11:29:13+09:00 Subject: Re: Why SVN? On 3/14/07, Brian Mitchell wrote: >> 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. It's an important metric for the measure of the quality of the tool. With more installations, it's significantly more likely bugs will be reported and (hopefully) fixed. > 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. I use Subversion primarily with RubyForge. I use Perforce at work. I haven't yet decided what I'll do for stuff that isn't for RubyForge or work; it's sort of sitting in limbo at the moment. (The decision will *really* come when I change my home server.) > 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). Be warned: Perforce is NOT cheap. However, we had what seemed to be an issue a few weeks back and they responded within four hours by email and kept the case open for two weeks following up to make sure that we were okay. I have nothing but praise for Perforce at this point. There's occasional merge issues, but for my money p4v is perhaps the best graphical interface for any SCM out there. If you've ever used TortoiseSVN, it's got some nice features, but p4v gives me the ability to see the diffs between any two revisions of a file dynamically ("time-lapse" view), which I use extensively when merging extensive changes that even normal diff produces ugly files for. That said, I still use the command-line tools extensively. > 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. Fair enough. However, the lack of a graphical tool for visualizing some of the branching concepts is, IMO, significant. > 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. My issue is more with centralised backup of changes. At work we back up a single machine and catch all of the committed changes. We're not yet using cheap developer branches, but as we start using the absolute raw power behind Perforce, you better believe we will. I also expect to be looking at p4proxy for use at home with the work server so that I can (hopefully) work disconnected without too much trouble. I have to see how well that works. > 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? It's the auxiliary tools and the centralized source for knowing what's going on with the source tree that matters to me. Patchset management is possible with Perforce, although I can't tell you exactly how you'd do it -- I haven't tried. Give me a way to work with Perforce without constantly being connected and I'll absolutely use it. But a DDSCM has to give me tools -- including GUI tools -- at least as good as and preferably better than what Subversion gives me as well as an assurance that I will be able to back everything up, then I will consider it. It also has to deal with the reality that I develop on a lot of different platforms, including Windows. -austin -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca