>
>
>> * Enterprise buzzwordiness. Some folks (for reason I neither
>> understand nor offer justification for) just don't feel good if
>> there data doesn't live in the database system they're forking
>> out the big bucks for.
>>
>>
>
>I do not agree with you here. I think that a SQL database offers a lot of
>possibilities. Just off the top of my head...
>
>1) Backup/recovery. fsfs has a great story here, but when compared to
>BDB, I think the issue is that many organizations already have tested
>[...]
>Thus it becomes a process that is always perceived as unique to
>Subversion.
>
>2) Scalability. I can picture a large hosting site like SourceForge
>[...]
>safely splitting the workload across machines.
>
>3) Transactions. Most SQL databases will have a robust implementation of
>[...]
>
>All this being said, when I originally came to Subversion a year+ ago I
>was sure that I needed a SQL backend someday. The fsfs backend has made
>me pretty much forget about it. That being said, I can still see that
>there could be some advantages for larger installations.
>
>Mark
>
>
>
Right now my company has finally given into the market and are migrating
various applications to live on top of mysql and oracle instead of our
own backends. The primary reason is in the larger IT organizations,
they UNDERSTAND oracle and mysql. They hate whenever people bring in a
new tool that messes up their domain
A example of this is,
SVN java api's were going to be used to version control some business
process models. Customer wishes to be able to snapshot the entire
system into backups and it was a issue that svn stores its info into a
file system instead of oracle. As a result, they decided to do their
own simple version control into oracle instead of using svn
--josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 7 20:26:21 2005