[Top][All Lists]

[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
>>> 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
>> 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
> 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.



P.S. Please reply me directly, I'm not in mail list.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]