John Szakmeister writes:
>
> ----- Erik Huelsmann <ehuels@gmail.com> wrote:
> > In the presence of svn:keywords or svn:eol-style, there's currently no
> > way to detect changedness of a file but to do a detranslation and
> > compare contents of the text file with its text base.
> >
> > 'svn status' does a full detranslate+compare for files which it has
> > reason to believe they might have changed: it checks for changed
> > mtimes. When working copies age, more and more files might have an
> > mtime which doesn't correspond with the one in the svn admin area
> > anymore. Thus in order to find modified files all those files will be
> > fully detranslated+compared.
> >
> > While a changed mtime can only indicate a file might have changed,
> > files which differ in size can't contain equal contents (on the
> > bit-level). So, we can sometimes shortcut the full detranslate+compare
> > cycle by just looking at the size of the file and comparing that to
> > the size when we created it. Files which have different sizes must
> > have changed.
>
So, in an aging working copy that get broken mtimes for some reason, but
still most of the files are unmodified (I think we can assume that most
people don't keep modified files for months and when the files are committed
/reverted, their mtimes will be reset in .svn/entries), we will still
have to do a byte-by-byte check of the files. We can't know that only
because the size hasn't changed, the file hasn't changed. So, in what
way does your proposal help this situation?
> I think someone raised a valid point about 3rd parties depending on
> the output of status, and expecting that anything in status will be
> committable. That would be the only reservation I have with this
> change. Unfortunately, we have no idea how this will affect 3rd
> parties. FWIW, any of the tools I've written would continue to
> work.
It was me who raised this point. If I remember correctly, TSVN uses
this strategy (please correct me if I am wrong) and it runs on a
platform where accidental LF -> CRLF might be more common than
others. If the tsvn people don't think this is a problem (or can work
around the problem(, then maybe I am overstating the problem.
Erik: I think this proposal is confusing. It talks about the mtime
problem of aging WCs, speed improvements and changed semantics. Maybe
I am following the list too sporadically, but I think it would help if you
clearly stated out the objectives of your work, the exact change to
the change detection algorithm and all the impacts it would have on all cases.
Also, your assumed common usecases would be good to include.
Thansk,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 10 15:02:26 2006