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

Re: Locking branch has been merged [Re: svn commit: r13571]

From: Travis <svn_at_castle.fastmail.fm>
Date: 2005-03-25 16:26:33 CET

On Mar 25, 2005, at 8:12 AM, Philip Martin wrote:

> Ben Collins-Sussman <sussman@collab.net> writes:
>> The entries file already caches repository
>> data (last-changed-rev, last-author, last-changed-date), thus making
>> 'svn info wc' and 'svn info URL' show nearly identical output.
> I have a patch for notes/wc-improvements that suggests removing those
> except where required by svn:keywords. Removing them would typically
> reduce the size of the entries file by one third, which might make for
> faster reading, writing and parsing.

Hmm, I'd be very unhappy by that change (removing them from being cached
for offline viewing within the WC; /where/ in the WC they are cached is
not so
important, so maybe moving them from WC to a separate cache file which
need so much re-writing is a compromise idea).

Just yesterday, I was recommending that we don't need $Id$ and similar
every one of our files because the information is always readily still
via 'svn info'. Not having keywords that are expanded and need
for lots of operations and not just by-and-for Subversion (referring
to some
of our own build-env related tools).

I also conjectured that not using expanding keywords would lend itself
to speeding up Subversion which doesn't necessarily need to make a
side copy with unexpanded keywords for diffing, etc. It's been my
to explicitly test that though I've not had the chance yet. (We're all
using \n Unix systems, so despite having eol-style=native, I believe
that that involves a no-op on our systems as well and I'm hoping that
svn doesn't create a side copy to make our \n's into \n's.)

-Travis Pouarz

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 25 16:30:46 2005

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.