You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@wandisco.com> on 2011/12/21 16:57:16 UTC

Re: [Issue 4084] FSFS and BDB store large directories inefficiently

On Tue, Dec 20, 2011 at 11:16 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 12/20/2011 11:54 AM, Daniel Shahaf wrote:
>>> Instead of continuing to envision incremental improvements to the various backends, why don't we just
>>> blow the whole thing up and come up with a design which meets the needs of the "modern" Subversion
>>> user?  This isn't the place to propose such a design, obviously, but I think this type of issue would be
>>> useful in the design of a future filesystem.
>>>
>>
>> What other needs would you like to see addressed?
>
> Oh, wow.  Floodgates opened.
>
> Rename tracking; performant revprop query capabilities; real FS ACLs (which
> follow their nodes); pluggable storage behind uniform business logic; better
> support for batch operations; line-based delta information caching (for
> blame); first class merge tracking support at the FS level; ...

What he said.

More generally, I'd like to go back to the paradigm of divorcing
content from structure.  We had this to some extent in BDB, but the
consequence of storing the data in BDB led to other problems, which
then led to FSFS.  However, I think the notion of a BLOB store vs. a
"structure" store is a valid one (and one that has been adopted
successfully by other systems, as well).

-Hyrum


-- 

uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/