[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-11-09 02:28:39 CET

Ben Reser <ben@reser.org> writes:

> On Mon, Nov 08, 2004 at 08:36:00AM -0600, kfogel@collab.net wrote:
>> Philip's mail was a little ambiguous, but I believe he was pointing
>> out that the .svn/README.txt file is not so necessary these days,
>> because a Google search for ".svn" turns up our home page anyway.
> Well I think basing a decision like this on what a google result returns
> today is pretty odd.

There are only two lines in README.txt, one is an instruction to visit
an URL. There are no references to any of the common Subversion
clients a user may have on their machine.

> I'd much rather see us remove the format file and merge its contents
> into the README.txt file.

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

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

(As an experiment I was going to try simply putting the version number
at the start of entries, and then reading it first before passing the
file handle to the XML parser.)

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 9 02:28:58 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.