# Why SVN? **URL:** \ **Category:** Ruby\ **Created:** [March 12, 2007, 8:26pm UTC](https://www.ruby-forum.com/t/why-svn/88576 "2007-03-12T20:26:32Z")\ **Posts on this page:** 11\ **Page:** 5
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 4:30am UTC](https://www.ruby-forum.com/t/why-svn/88576/81 "2007-04-05T04:30:40Z")
Ryan D. wrote: > I’ve seen too much SVN corruption already to trust it. Using the BDB store or files? ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 5:16am UTC](https://www.ruby-forum.com/t/why-svn/88576/82 "2007-04-05T05:16:45Z")
On Apr 4, 2007, at 19:30 , Clifford H. wrote: > Ryan D. wrote: > > > I’ve seen too much SVN corruption already to trust it. > > Using the BDB store or files? Should it matter? SVN corruption is SVN corruption. That said, I dunno. I wasn’t privy to the server’s setup. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 5:48am UTC](https://www.ruby-forum.com/t/why-svn/88576/83 "2007-04-05T05:48:47Z")
Ryan D. wrote: > On Apr 4, 2007, at 19:30 , Clifford H. wrote: > > > Ryan D. wrote: > > > > > I’ve seen too much SVN corruption already to trust it. > > > Using the BDB store or files? > > > Should it matter? > > > Should? No. Does? Yes. [Strategies for Repository Deployment](http://tinyurl.com/39qetn) ([svnbook.red-bean.com](http://svnbook.red-bean.com)) Devin ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 11:31am UTC](https://www.ruby-forum.com/t/why-svn/88576/84 "2007-04-05T11:31:55Z")
On Apr 4, 2007, at 20:47 , Devin M. wrote: > Ryan D. wrote: > > > On Apr 4, 2007, at 19:30 , Clifford H. wrote: > > > > > Ryan D. wrote: > > > > > > > I’ve seen too much SVN corruption already to trust it. > > > > Using the BDB store or files? > > > > Should it matter? > > > > Should? No. Does? Yes. [Strategies for Repository Deployment](http://tinyurl.com/39qetn) (svnbook.red- > > > > [bean.com](http://bean.com)) Does? No. ANY (recent) amount is too much. There are enough options available where I don’t need to pick from the scary ones. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 11:40am UTC](https://www.ruby-forum.com/t/why-svn/88576/85 "2007-04-05T11:40:59Z")
On Apr 4, 2007, at 20:47 , Devin M. wrote: > Ryan D. wrote: > > > On Apr 4, 2007, at 19:30 , Clifford H. wrote: > > > > > Ryan D. wrote: > > > > > > > I’ve seen too much SVN corruption already to trust it. > > > > Using the BDB store or files? > > > > Should it matter? > > > > Should? No. Does? Yes. [Strategies for Repository Deployment](http://tinyurl.com/39qetn) (svnbook.red- > > > > [bean.com](http://bean.com)) This is the last I’ll speak on this topic. I promise… % curl -s [http://svn.collab.net/repos/svn/trunk/CHANGES](http://svn.collab.net/repos/svn/trunk/CHANGES) | egrep -ic “dataloss|corrupt” 16 Including… SURPRISE! In the very latest release!!! and 5 in the last year alone (since sept 2006 actually). So does the storage type matter??? Hell no. Not with that track record. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 2:06pm UTC](https://www.ruby-forum.com/t/why-svn/88576/86 "2007-04-05T14:06:10Z")
Ryan D. wrote: > % curl -s [http://svn.collab.net/repos/svn/trunk/CHANGES](http://svn.collab.net/repos/svn/trunk/CHANGES) | egrep -ic > “dataloss|corrupt” > 16 > > Including… SURPRISE! In the very latest release!!! and 5 in the last > year alone (since sept 2006 actually). The only problem with Perforce is money… Lots of them. Of course in professional businesses it is a question “money or safety”. Sad that often money option wins… As for private/small team use Subversion is quite good. I’ve also been trying out Bazaar and it looks good too. > **[Bazaar-NG: private repositories on shared hosting](https://dentharg.wordpress.com/2007/02/14/bazaar-ng-private-repositories-on-shared-hosting/)** > > A simple, walk through, HOWTO document talking about setting up a private repository on shared hosting using Open Source tool Bazaar. Basic introduction to DRCS/DSCM. Cheers, -Marcin ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 3:31pm UTC](https://www.ruby-forum.com/t/why-svn/88576/87 "2007-04-05T15:31:44Z")
Ryan D. wrote: > This is the last I’ll speak on this topic. I promise… > > % curl -s [http://svn.collab.net/repos/svn/trunk/CHANGES](http://svn.collab.net/repos/svn/trunk/CHANGES) | egrep -ic > “dataloss|corrupt” > 16 > > Including… SURPRISE! In the very latest release!!! and 5 in the last > year alone (since sept 2006 actually). > > So does the storage type matter??? Hell no. Not with that track record. > Nothing is 100 percent free of data loss or corruption. Not Linux. Not > BSD. Not Windows. Not Solaris. And not _any_ source code repository or > other application built upon them, free as in freedom, free as in beer > or expensive as all get out. This is why we RAID our disks and perform > frequent backups, live mirror if we need hot backup, and pay our > operations staff. There are only two kinds of data in the world: those that have been backed up and those that have not yet been lost. – M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P) [http://borasky-research.blogspot.com/](http://borasky-research.blogspot.com/) If God had meant for carrots to be eaten cooked, He would have given rabbits fire. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 3:08pm UTC](https://www.ruby-forum.com/t/why-svn/88576/88 "2007-04-05T15:08:41Z")
On 4/5/07, Marcin G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Ryan D. wrote: > > > % curl -s [http://svn.collab.net/repos/svn/trunk/CHANGES](http://svn.collab.net/repos/svn/trunk/CHANGES) | egrep -ic > > “dataloss|corrupt” > > 16 > > Including… SURPRISE! In the very latest release!!! and 5 in the last > > year alone (since sept 2006 actually). > > The only problem with Perforce is money… Lots of them. > > Of course in professional businesses it is a question > > “money or safety”. Sad that often money option wins… 1. For open source projects, Perforce can be free. 2. For commercial projects, it often is a matter of “you get what you pay for.” Part of the benefit of Perforce is rock-solid technical support. You _pay_ for the support in terms of a per-user annual contract, but that doesn’t change the quality of the support you get (I am speaking from personal experience here). There are things that you need to understand with Perforce, and i’m sure we’re not taking advantage of a quarter of what Perforce actually offers us (and could probably boost performance without having boosted the hardware), but if I were a company, I wouldn’t want to use anything else for my primary source repository. -austin ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 3:50pm UTC](https://www.ruby-forum.com/t/why-svn/88576/89 "2007-04-05T15:50:06Z")
> Including… SURPRISE! In the very latest release!!! and 5 in the > last year alone (since sept 2006 actually). > > So does the storage type matter??? Hell no. Not with that track record. As someone else said, every product has defects that can cause data corruption, including Perforce ([http://public.perforce.com/public/perforce/faq/admin.html](http://public.perforce.com/public/perforce/faq/admin.html)). They wouldn’t need recovery procedures for corrupted databases if they couldn’t get corrupted. What matters is how reliably the product performs in the real world. And that, barring some study proving it, is a personal opinion based on your experience and what others say of their experience. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 4:08pm UTC](https://www.ruby-forum.com/t/why-svn/88576/90 "2007-04-05T16:08:54Z")
On 4/4/07, Ryan D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > backups. I simply can’t say that about much of any other VCS out > there (except the nice stable old ones, like CVS). Speaking as someone who was tasked with setting up and administering a CVS server for a small team a couple years ago: AHAHAHAHAHAHAHAHAHAHAHA. CVS stable? Trust CVS with your data? That’s rich. I’m not saying any other system is necessarily better; but treating CVS as some kind of gold standard of reliability is hilarious. We’re talking about a system that can’t even guarantee atomic commits. And for which maintenance releases sometimes randomly break major features and have to be manually patched. And which requires having a sysadmin (or a knowledgeable user) around to periodically clean up orphan lockfiles which break the repository. The only thing CVS has going for it is that it is simple, comparatively speaking. And often that’s the most important consideration. But it’s only stable and reliable in comparison to Visual Source Safe. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [April 5, 2007, 4:57pm UTC](https://www.ruby-forum.com/t/why-svn/88576/91 "2007-04-05T16:57:59Z")
Believing that any information medium is infallable? Plain foolish. Paper? Magnetic tape? Optical media? Stone tablets? Oil paint? Software works on at least a few of these. Software also operates under Murphy’s law. If you want a modicum of reliability, do like the military: multiple redundancy! That means use Raid Mirroring, on-site + off-site, use multiple systems? Or best of all: don’t be overly concerned about it. Accept the fact that some versions saved will be corrupted and none will last forever. Be realistic and plan for contingencies, but don’t freak out when they happen. [Previous page](https://www.ruby-forum.com/t/why-svn/88576.md?page=4)