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

Re: Caching text-size in the entries file

From: Peter Lundblad <plundblad_at_google.com>
Date: 2006-11-06 08:56:42 CET

Erik Huelsmann writes:
> > This change will mean:
> >
> > - That we will be marking files which have edited keyword values as
> > modified (we currently don't: we detranslate, making those changes
> > invisible)
> > - That we will be marking files with changed sizes as modified - even
> > if the mtime hasn't changed - which we currently don't (they show up
> > as unmodified)
> > - We will gain 'svn status' speed with many changed files and
> > svn:keywords (but no extra stat() calls for the case of where no files
> > changed)
> > - We gain some independence from mtimes
>
> Given the lack of negative responses, I'm going to update the code for
> current trunk and commit a change to this effect sometime next week.
>

Sorry for not paying attention earlier, but I am not sure I like this
speed vs. correctness tradeoff. I think it is confusing to users to show
files as modified that won't be modified in a commit.

Also, I think this has a compatibility impact. Currently, if you
call the status API and that returns the file as modified, then commit will
include it in the transaction. Users of the library might rely on this
semantic. If you have files that look modified before a commit, will
you still have those files look modified after the commit because they
were not considered modified by commit? Maybe the commit code could
detect and fix this?

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 6 08:57:03 2006

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.