Re: svn does not detect file recodings as changes

On 2007-02-19 13:50:22 -0500, Duncan Murdoch wrote:
> On 2/19/2007 1:29 PM, Lukas Reck wrote:
> >svn only uses the mtime comparison as a shortcut to avoid doing a
> >full binary compare on all files. I fail to see why users could
> >need to control that behaviour.
>
> Why would users want to modify a file but not change the mtime?

Several reasons:

  * For recode, because the contents don't change semantically: in
    practice, users view a file as a sequence of characters, not a
    sequence of bytes. They probably want to keep the mtime because
    they need a way to know when the contents (as a sequence of
    characters) were changed last time, and they don't have another
    field for that. However, Subversion should still report the diff.
    If one day, Subversion has a way to deal with file encoding (e.g.
    via a property svn:encoding), then it could have an option to
    regard an encoding change as an unmodified file, but I doubt that
    this would be useful anyway.

  * For patch -T or -Z, because "make" rules are based on timestamps.
    But also, though the contents change locally, they don't if you
    compare them to the remote file (i.e. you can see diff/patch as
    a way to transmit files cheaply).

  * For mv (please don't say to use "svn mv", because one doesn't
    necessarily want to keep the history and because the source file
    is not necessarily a versioned file), because the contents don't
    change if you compare them to the source file. Ditto for unzip,
    gunzip, scp -p, and so on.

> Perhaps they want some programs to treat the file as if it is
> unmodified. How is svn to know whether it is one of those programs
> or not?

Because it is not documented, and probably not wanted by any user.
If such a feature is included in Subversion, then there must be an
option to control it (like with most commands).

> >If they change a file's contents (and thus update the ctime), they
> >normally want those changes to be commited.
>
> And if they change the file's contents, they normally update the mtime.

No, see above. And in general, in a file system, if two files have
the same timestamp, you cannot deduce that they are identical (in
particular due to the time resolution).

> We're talking about an abnormal case here, where a user has made a
> choice to change a file but not to appear to have changed it.

It is not necessarily a user choice. The mv behavior is required
by POSIX, for instance. What if you checkout two repositories at
the same time and move some files from a working copy to the other
one (and overwrite some files at this occasion)?

> >At worst, using ctime instead of mtime will result in doing some
> >more binary compares.

The old algorithm was using ctime and AFAIK, no-one complained on
this point. The change was done only because of Windows.

BTW, "svn export" still set the mtime to the commit time.

-- 
Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org