Ryan D. wrote:
I’ve seen too much SVN corruption already to trust it.
Using the BDB store or files?
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.
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 (svnbook.red-bean.com)
Devin
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 (svnbook.red-
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.
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 (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.
Ryan D. wrote:
% curl -s http://svn.collab.net/repos/svn/trunk/CHANGES | egrep -ic
“dataloss|corrupt”
16Including… 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 D. wrote:
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”
16Including… 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/
If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.
On 4/5/07, Marcin G. [email protected] wrote:
Ryan D. 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…
- For open source projects, Perforce can be free.
- 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
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.
On 4/4/07, Ryan D. [email protected] 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.
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.