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

Re: [PATCH] Remove .svn/README.txt

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-11-09 03:38:14 CET

Philip Martin <philip@codematters.co.uk> writes:

> > An alternative would be to remove README.txt and merge it into format.
> > But I prefer README.txt as a name. Either way the majority of the
> > benefits of getting rid of README.txt can be gained by merging the two
> > files into one.
>
> In my opinion the information in README.txt is of no real use.

I agree with this sentiment. As Subversion use becomes more
widespread, people will know what a .svn directory is just like they
know what a CVS directory (and if they don't, a little google -- first
hit or not -- will do the trick). Lose the README.txt file.

> From a performance point of view I'd like to get rid of both format
> and README.txt, and put everything in entries. Having to read two
> files, rather than one, to open an access baton is silly. Even if
> the format file contents don't represent much load on the OS,
> accessing the file will cause a load on the inode cache. What is
> the effect of opening 168 format files, how many files get pushed
> out of the inode cache?

This is almost a no-brainer optimization, because we read the entries
and format files in conjunction so often. My only (small) concern is
that if the format number is inside the entries file, we have to start
reading that file without knowing what format to expect the
information to be in. If we happen to lose XML in our entries files
altogether (or something like that), the format version change can't
be noticed before firing up the wrong kind of parser.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 9 03:41:02 2004

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.