why do you think a database has a few files and not 200.000? and even
includes blobs/clobs? do you think db designers are all idiots? of
course not, you use a db for the server and are quite happy with it.
from far, it looks like you defend this client design just cause you
did the design.
now the details:
the figure is NOT off, it depends on the structure of your code. we
have 25.000 entries, and 280.000 in the admin-area (ls -1R | wc, ls
-1aR | wc).
this includes the tmp, which is a strange construct by itself, cause
it clashes with standard disk management strategies of putting
temporary things in /var/tmp, or some "$tmp".
and you create locking files on every folder, nearly every time, and
have to remove it again.
and if you have a "copy", you have this "cheap" thing twice on the
client ... but you only need it twice for the working copy files (not
for the administrative area).
now to your arguments:
1. cmpilato: don't put text-base in entries file.
ok. nobody suggested that.
if svn client would use bdb, and you can do a diff without
"materializing" the file in the file-system, than yes, store it in
the db ...
2. branko: properties can be theoretically huge.
ok. but only theoretically. i asked for examples,
and nobody had one.
so there is no point in providing this
theoretical thing for 1.0. and properties
are responsible for the majority of files in
the admin-area.
3. robert: disk space is cheap.
thats correct, but creating, accessing and deleting these files is
not. if we do "svn up" the disk is blocked for 2 minutes. svn client
is one of the best programs for disk stress test i can imagine.
i suggested (all of the points are absolutely independent):
- do locking in a more intelligent way
(--> use bdb, use top-level "locking file", ...)
this is 30% of an empty update runtime.
- remove the subdirectories (not the contents of them!)
--> no loss at all, just different naming.
- remove "auth" completely
- pull the "props" into the entries file immediately
with a mechanism to store huge properties efficient
in post 1.0.
everybody who posts that the number of files has no influence did not
ever try to use the client with a reasonable amount of administered
folders on a (windows) network share. you don't need 25.000
files/folders to experience this.
--- Michael Price <mprice@atl.lmco.com> wrote:
> Robert Pluim writes:
> > solo turn writes:
> > > currently svn client stores minimum 10 times as many
> files/folders in
> > > the administrative area as files/folders administered.
> >
> > So what? Disk space is cheap (and I don't believe you about
> that 10x
> > figure).
>
> Yes, his figure is a bit off. You get 3 new files for every
> versioned
> file and 4 files plus 6 directories for every versioned directory.
>
> Michael
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 5 18:32:58 2003