Is it possible to store Subversion meta data in SQL Server? We want a SQL Server based Subversion.
+3
A:
There isn't anyway to do that right now. Subversion lets you choose between FSFS and Berkeley DB, with FSFS being the better choice for most people. (Berkeley DB has some issues around getting corrupt).
Is there a reason you want to store the data in SQL Server?
James Avery
2009-04-22 15:49:09
FSFS = File System File System, oddly enough. This referring to the fact that it implements the Subversion "file system" on top of a plain file system, as apposed to on BDB.
bendin
2009-04-22 19:49:54
Weird, I removed what I thought FSFS stood for (which is also in wikipedia) but I can't confirm anywhere in the Subversion stuff.
James Avery
2009-04-22 23:43:05
+1
A:
Subversion used to have BDB (Berkley Database) as its core storage. Most people moved away from that because it was hard to back up and corruption sometimes became an issue. I wouldn't recommend it but I am sure you could go look at the BDB code and have it hook up to a SQL Server.
trent
2009-04-22 15:50:23
+2
A:
I with James Avery - why do you want to store the data in an SQL Server? If you're wanting someway to interface with the underlying subversion data from a .NET library, check out SharpSVN: http://sharpsvn.open.collab.net/.
Matt
2009-04-22 16:14:19
>>>why do you want to store the data in an SQL ServerConvenience, querying, you name it. The benefits of a DB!
CoffeeAddict
2009-04-22 17:22:43
I think sure file system is faster BUT why not a DB that you can code against, export, change data, whatever. Even if it's meta data you can query on shit
CoffeeAddict
2009-04-22 17:23:19
Using the API you can still code against the subversion repository in FSFS. epxort etc.
Jafin
2010-06-01 01:08:38
A:
Why use a backing store that you can so easily corrupt? Sure, you can corrupt the filesystem store, but most people have enough sense not to touch it.
As it is, future versions of SVN are looking to store revprop data in a sqlite db instead of files. If they do, then you should be able to access that in much the same way, but for the mutable revprops only. I'm not sure if they intend to restrict access to it to the svn libraries of allow any other process to read and write to it.
Of course, the biggest reason SQL server is not suitable for subversion is that it would completely break its ability to be cross-platform.
gbjbaanb
2009-05-20 22:03:47
I think the biggest reason may be that storing source code (inc binaries) makes more sense in a file or document (nosql) datastore rather than a relational database.
Jafin
2010-06-01 01:10:27