[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: This'll give ya whiplash

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 1 Oct 2008 19:05:06 -0700

On Wed, Oct 1, 2008 at 5:30 PM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>> Oh yeah... watch out DVCS's .... I'm gonna add offline commits to svn,
>> and write a revlog-backed repository. It'll take me a while, but I'll
>> get there... Then let's look at feature/function deltas!
>> Bwahahahaaaa!!
>
> Maybe you could start by implementing merge-tracking that
> actually works. And maybe these other projects will not stand
> still, either.

Oh, don't throw me into the merge tracking lump. I'm gonna work on
frying some other fish, thankyouverymuch.

(and yeah, you can color me peaved, too)

> As for revlog, I don't understand the attraction. Fsfs has the

We went through this at the first svn conference at google. 2? 3?
years ago. As I recall, revlog has some excellent performance
characteristics across the set of potential operations. What I took
away was "wow. sounds great. could be a big benefit." ... but I have
not looked/grokked it to really be able to talk about it myself. Just
what I remember as a takeaway.

> beautiful property that revision data, once written, never
> changes. This greatly simplifies a large-scale deployment,
> enables caching on the servers, and enables simple, almost
> entirely lock-free multi-writer capability. Last I heard[1],
> Mercurial did not support multiple simultaneous writers.

Yah. That would be a non-starter.

> Perforce is all about locks, locks, locks, and more locks to
> support multiple writers. Would fs_revlog be the same?

I'm with you: if it had much locking... back away.

> That's not to say fsfs has no problems or can't be improved.
> But I'm skeptical deltification is useful in storage. I'd be
> more interested in seeing how individually compressed texts in a
> content-addressable store performs.

That would certainly be an interesting approach, and I think it works
great for files up to a specific size. For large files, then I think
you might start chewing through space "too quickly".

Then again, it might be interesting to say "fuck it" and just use the
disk space. "So what? That's on ONE machine. The clients don't each
have to have a terabyte. But the server? Sure. A terabyte? That is ONE
DISK DRIVE. Now shut up, and go install a second terabyte."

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-02 04:05:17 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.