[RFC] Possible Working Copy refactoring...

[Steve Dwire <sd...@parkcitysolutions.com>]

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

Re: [RFC] Possible Working Copy refactoring...

["C. Michael Pilato" <cm...@collab.net>]

Greg Hudson <gh...@MIT.EDU> writes:

> The key point here is that the RA and FS APIs were designed with
> multiple implementations in mind, while the WC API has experienced much
> more evolution than conscious design.

s/evolution/devolution/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [RFC] Possible Working Copy refactoring...

[Greg Hudson <gh...@MIT.EDU>]

On Thu, 2004-09-02 at 12:46, Steve Dwire wrote:
> 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. 

The key point here is that the RA and FS APIs were designed with
multiple implementations in mind, while the WC API has experienced much
more evolution than conscious design.  We've long acknowledged that the
WC library needs a redesign (although the scope of that redesign isn't
well-understood: do we preserve the on-disk format?  Do we preserve the
API?  Do we implement the current API as a compatibility layer on top of
the new one?).  That redesign would probably need to happen before we
could support multiple WC implementation.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org