[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: "cvs move" command
From: |
Andrew Volkov |
Subject: |
Re: AW: "cvs move" command |
Date: |
Tue, 21 Jan 2003 21:31:08 +0300 |
Hi Matt,
>>> ``Moving a file to another directory becomes a bit of a challenge, since
we
>>> now have a mapping that spans a single directory. So some means of
>>> linking these PDDB`s must be developed. I could actually envision a
>>> repository structure where EVERY file is stored in the same flat
>>> directory.''
>> My thougts. The only thing I'm concerned about is that the ext2 file
system
>> would have it's problems with this, as it's performance slows down with a
>> high amount of files in a single directory. But that's a system specific
>> problem and guess this doesn't account to the new ext3 file system.
> As far as I recall, doesn't ext3 use the same layout on disk, plus
journalling info?
> ReiserFS may be better - wasn't it designed for different usage scenarios?
> http:// www.namesys.com/ for more info..
> Perhaps it would be better to store all the files in a database, rather
than
> many-files-in-one-directory. Hashing the files across a tree of
directories would be better,
> although what could you use as the hash key? You couldn't use file name,
since in a rename/move,
> that'd change..?
IHMO, it would be VERY BETTER to store in dbase (MySQL as first candidate, I
think), in this
case you may not trouble about hash, will get right rolling back (in case,
if dbase support transactions), simplify administration, GUI clients,
backup/restore ...
But, I admit, translating tree structure of projects to tables will eat
more (I presume very more) space and performance then build same over FS :(.
For me it's
along reason, why converting cvs to dbase is problematically.
Comments?
Regards,
Andrey
P.S. Please reply me directly, I'm not in mail list.