Background: Way back in Subversion's history, people recognized the
benefits to having a choice about where their repositories are stored,
rather than being locked into the Berkeley DB. To address this need,
Glenn A. Thompson (GAT) proposed a refactoring for Subversion's
repository layer to allow it to support "pluggable" repository
back-ends, including a SQL back-end.
I'm now looking at a similar situation, but for the WC layer instead.
I'd like to choose where my working copy is, rather than being locked
into using the OS filesystem. "Why?" you may ask... Well, not every
development environment keeps its working resources in distinguishable
filesystem files. At our company, for example, we have a document
management system with our own API for storing XML documents in a
somewhat proprietary storage database. I'd like to use Subversion as our
version-control manager to keep multiple development databases, staging
databases, and production databases in sync with each other during team
development. Others have simply wanted a way to store the .svn
meta-information outside of their development directories.
At this point, I'm just looking for a sanity check.
Does anyone else see any value in having "pluggable" working copy
managers? I'm considering starting a GAT-style "here's what it would
take" kind of draft document. Unfortunately, I haven't spent a lot of
time in libsvn_client and libsvb_wc to know what that document would
look like, and I'd rather use my time on more productive things if folks
think this is a bad idea or has little value.
So, whatcha think, folks? Is it worth it? Are there any reasons it's a
BAD idea? Does anyone else see the need to do version control on working
resources stored somewhere other than a filesystem directory?
--Steve Dwire
Received on Thu Sep 2 18:47:10 2004