On 11/6/06, Peter Lundblad <plundblad@google.com> wrote:
> 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.
Ah, we already have a speed-vs-correctness tradeoff in status: we use
mtimes instead of filecomparison or hash calculation. BTW: I do feel
that some speed improvements are worth more than others; this one is a
factor 18 for translated files. I think that's a lot to gain. (Just
yesterday had I a user complaining on IRC about our speed in the
presence of keywords...)
> 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?
That's no problem. Ofcourse it could do that (post-commit!). But how
about those files that are currently modified but look unmodified
because of detranslation? We don't do anything about those, do we?
But, not all files reported as not-modified are not modified: we even
have a test which creates an inconsistent new line in a file (by
replacing CRLF with LF). Currently status says the file isn't
modified, but if you have software which only tolerates CRLF, it
*does* consider it modified.
Why I think this change is important is: I think we should report
'Modified' as close as we can to the file actually having been
modified (as viewed by the user).
Aren't we always going to confuse some users in some cases by doing
translation anyway?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 6 09:29:05 2006