On Sun, Dec 12, 2010 at 4:23 PM, Stefan Fuhrmann
wrote:
> On 19.10.2010 15:10, Daniel Shahaf wrote:
>>
>> Greg Stein wrote on Tue, Oct 19, 2010 at 04:31:42 -0400:
>>>
>>> Personally, I see [FSv2] as a broad swath of API changes to align our
>>> needs wit
On 19.10.2010 15:10, Daniel Shahaf wrote:
Greg Stein wrote on Tue, Oct 19, 2010 at 04:31:42 -0400:
Personally, I see [FSv2] as a broad swath of API changes to align our
needs with the underlying storage. Trowbridge noted that our current
API makes it *really* difficult to implement an effective
On 19.10.2010 15:10, Daniel Shahaf wrote:
Greg Stein wrote on Tue, Oct 19, 2010 at 04:31:42 -0400:
Personally, I see [FSv2] as a broad swath of API changes to align our
needs with the underlying storage. Trowbridge noted that our current
API makes it *really* difficult to implement an effective
[Peter Samuelson]
> Another minor correction, or perhaps a minor minor-correction
> correction: "fair accompli" (literally "finished work") has no d'.
_fait_ accompli! Of course when I get pedantic I misspell.
http://linuxmafia.com/~rick/lexicon.html#moenslaw-corrections
> On Tue, 2010-10-19 at 04:31 -0400, Greg Stein wrote:
> > The FSFS backend was dropped in as a fait d'accompli.
[Greg Hudson]
> A minor correction: ra_svn was dropped in as a fait d'accompli.
Another minor correction, or perhaps a minor minor-correction
correction: "fair accompli" (literally "f
* difficult to implement an effective backend. I'd
also like to see a backend that allows for parallel PUTs during the
commit process. Hyrum sees FSv2 as some kind of super-key-value
storage with layers on top, allowing for various types of high-scaling
mechanisms.
How would that API look?
ifficult to implement an effective backend. I'd
>> also like to see a backend that allows for parallel PUTs during the
>> commit process. Hyrum sees FSv2 as some kind of super-key-value
>> storage with layers on top, allowing for various types of high-scaling
>> mechanisms.
>
On Tue, Oct 19, 2010 at 12:12 PM, Blair Zajac wrote:
...
> 3) Pools are painful to use. We have repository, revision and transaction
> C++ objects stored in an LRU cache. They cache revision and transaction
> roots for improved performance. Using the wrong pool for a RPC method can
> cause memo
also
find a link to the Subversion Meetup wiki page:
http://subversion.open.collab.net/wiki/ApacheConNA2010Meetup
That's the first mention I've seen of FSv2. What ideas are going into it?
What problems is it primarily meant to solve?
FSv2 is a hand-wave.
Personally, I se
On Tue, Oct 19, 2010 at 11:04, Greg Hudson wrote:
> On Tue, 2010-10-19 at 04:31 -0400, Greg Stein wrote:
>> The FSFS backend was dropped in as a fait d'accompli.
>
> A minor correction: ra_svn was dropped in as a fait d'accompli. FSFS
> was, as far as I remember, a pretty open process where I cre
On Tue, 2010-10-19 at 04:31 -0400, Greg Stein wrote:
> The FSFS backend was dropped in as a fait d'accompli.
A minor correction: ra_svn was dropped in as a fait d'accompli. FSFS
was, as far as I remember, a pretty open process where I created a
design and Josh Pieper implemented it. You can look
Greg Stein wrote on Tue, Oct 19, 2010 at 04:31:42 -0400:
> Personally, I see [FSv2] as a broad swath of API changes to align our
> needs with the underlying storage. Trowbridge noted that our current
> API makes it *really* difficult to implement an effective backend. I'd
> a
>> find a link to the Subversion Meetup wiki page:
>>
>> http://subversion.open.collab.net/wiki/ApacheConNA2010Meetup
>
> That's the first mention I've seen of FSv2. What ideas are going into it?
> What problems is it primarily meant to solve?
FSv2 is
13 matches
Mail list logo
