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

Fwd: Subversion Compressed Pristines Design

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 22 Mar 2012 03:25:23 -0400

Again, pulling commentary up out of the HTML:

* I'm unclear on what you mean by "no limitations", as your design doc
clearly states 16MB file size limits, and 64k of those files. Thus, 1TB of
content. Now... elsewhere, you also state that a single (pack) file may
exceed the normal limit, for purposes of keeping an entire pristine within
a single file. These two design points are a bit contradictory.

* In any case... 1TB is certainly not large enough for the pristine content
store. I've personally witnessed 10GB working copies. I will bet others on
this list have seen larger. 10GB is just two orders of magnitude less than
1TB. We need better future proofing. I'd like to see a pristine store that
can accommodate 1PB, minimum. The current store has no limit, so if one is
to be applied, then it better be very generous.


---------- Forwarded message ----------
From: ashodnakashian (Google Docs) <
Date: Thu, Mar 22, 2012 at 00:03
Subject: Subversion Compressed Pristines Design
To: gstein_at_gmail.com

ashodnakashian added comments to Subversion Compressed Pristines
[image: Greg Stein]
*Greg Stein*

This section reminds me of "generational scavenging". Also similar to
LevelDB's multi-level storage system.
[image: ashodnakashian]

Sounds like something you like - always good thing :)

Yes, that is very similar to what I had in mind. In fact, I event imagined
that by adding file revision numbers in the index file, we can store
historic revisions (at least some of them) and give the user the ability to
accumulate a number of historic revisions for faster diff/restore with them
at the expense of storage. But that is out of scope, so I left out
speculating about it.
[image: Greg Stein]
*Greg Stein*

That isn't large enough. Some people have REALLY huge working copies. Think

(yes, I'd agree that it's likely nobody has one this large, but I wouldn't
be surprised at all by working copies in the multi-100GB range)

We need to design well ahead of the curve here.
[image: ashodnakashian]

There are no limitations inherent anywhere. I've made a very conscious
effort to be forward compatible and resilient to arbitrary limitations.
However you can't make everything 128-bit "just in case".

So my initial "sane" goal is 1TB (I found this to be a "reasonable" minimum
to support.) Having said that, The number of pack store files and the limit
on each are both subject to tuning based on hard numbers. So I'd like to do
benchmarks and we should find out the right balance *for the target minimum
that we agree on*.
[image: Greg Stein]
*Greg Stein*

That is not a design goal, so it is not a limitation. We do not want any
external tools/processes monkeying around with files under .svn
[image: ashodnakashian]

Fair enough.
You received this email because you are a participant in the updated
comment threads.Change<https://docs.google.com/document/docos/notify?id=1ktIsewfMBMVBxbn-Ng8NwkNwAS_QJ6eC7GOygsbBeEc&title=Subversion+Compressed+Pristines+Design>what
Google Docs sends you.You
can not reply to this email.

Received on 2012-03-22 08:26:00 CET

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