To me, that only sounds like an argument against using Visual Source Safe 
Well, that's just a given.
As far as backing up an SVN repository (especially if it's using the
file system instead of BDB) tar does a pretty good job.
I think this is part of the problem. I don't want to think about what storage mechanism it uses (past an evaluation stage at least). I don't want to have to think: Did they test this storage format as well as the previous? What are the repercussions of using this over the other (eg http vs svn protocol)? I just want it to work so I can do the same.
I've seen too much SVN corruption already to trust it.
···
On Apr 4, 2007, at 12:09 , Kyle Schmitt wrote:
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.
···
On Apr 5, 2007, at 11:07 PM, Avdi Grimm wrote:
On 4/4/07, Ryan Davis <ryand-ruby@zenspider.com> 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.
--
Avdi
Ryan Davis 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.
···
On Apr 4, 2007, at 19:30 , Clifford Heath wrote:
Ryan Davis wrote:
I've seen too much SVN corruption already to trust it.
Using the BDB store or files?
Does? No. ANY (recent) amount is too much. There are enough options available where I don't need to pick from the scary ones.
···
On Apr 4, 2007, at 20:47 , Devin Mullins wrote:
Ryan Davis wrote:
On Apr 4, 2007, at 19:30 , Clifford Heath wrote:
Ryan Davis 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 (svnbook.red-bean.com)
This is the last I'll speak on this topic. I promise...
% curl -s 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.
···
On Apr 4, 2007, at 20:47 , Devin Mullins wrote:
Ryan Davis wrote:
On Apr 4, 2007, at 19:30 , Clifford Heath wrote:
Ryan Davis 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 (svnbook.red-bean.com)
Ryan Davis wrote:
% curl -s 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.
Cheers,
-Marcin
Ryan Davis wrote:
Ryan Davis wrote:
Ryan Davis 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 (svnbook.red-bean.com)
This is the last I'll speak on this topic. I promise...
% curl -s 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.
···
On Apr 4, 2007, at 20:47 , Devin Mullins wrote:
On Apr 4, 2007, at 19:30 , Clifford Heath wrote:
--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/
If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
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\). 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.
···
--
Posted via http://www.ruby-forum.com/\.
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
···
On 4/5/07, Marcin Gil <marcin.gil@nospamgmail.com> wrote:
Ryan Davis wrote:
> % curl -s 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..
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca