Erik Huelsmann writes:
> Ah, we already have a speed-vs-correctness tradeoff in status: we use
> mtimes instead of filecomparison or hash calculation. BTW: I do feel
Yeah, but I think we need to be careful when making the heuristic worse.
> 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...)
>
Is this when most (all?) of the files are modified?
> > 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?
>
Do you mean modification that would be "normalized away" in the repository?
> 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.
>
I think here is where our views differ. I have always assumed that
modified as reported by status means modified compared to the base
revision, not compared to what the text base looked like when it was
checked out. This means that a file that status says is modified will
look different if committed, compared to the base revision.
> 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).
>
So, is this a speed improvement or a semantic improvement? If we implement
this change, we need to make sure we are consistent. Either a file
with mods inside keyword expanded parts is modified or not according
to status. This must not depend on whether the size is the same or
not. I would prefer that we discuss the semantic change separately
from the optimization. If we can agree that your proposed new
semantics are correct, then we can discuss performance improvements.
> Aren't we always going to confuse some users in some cases by doing
> translation anyway?
>
Probably:-) But we could at least be consistent.
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 09:44:01 2006