"Delbert D. Franz" <ddf@sonic.net> writes:
> However, some subtle problem with files on an NTFS drive
> is leading Subversion to conclude that files have been changed
> when in fact an external diff program shows that not one byte has changed.
>
> I have placed a small repository on my server that is
> about 40 KB in size and involves a few directories and
> files. It can be checked out at :
>
> http://www.iqdotdt.com/svn/testsvn/trunk/testsvn
The problem is that the text-base in the repository has CRLF line
endings. This is an error, the text-base is supposed to have LF line
endings.
What happens is that when you checkout a working copy it sets the
working copy timestamp to that of the text base and then uses the
matching timestamps to avoid doing a byte-by-byte comparison. Thus
the newly checked out working copy appears to be unmodified.
When you archive/extract using your broken tools they modify the
working copy timestamps. This causes the timestamp comparison to fail
and Subversion falls back on a byte-by-byte comparison, which reveals
the incorrect eols in the text-base. Breaking the timestamps like
this will also make Subversion much slower.
If you modify the timestamp of one of the files in the original
"unmodified" working copy then it too will show up as modified. If
you commit these "modified" files it will correct the line endings in
the repository and the problem will go away.
I never liked eol-conversion. Nobody knows exactly how it should work
in some corner cases, and I suspect nobody can say how it currently
works without looking at the code[1]. It works most of the time, but
this problem with incorrect line endings in the repository has been
reported before. Nobody with a Windows box has tracked it down, I
don't know if they ever tried.
[1] The corner case: during an update with locally modifed files a
three way merge is attempted. There are three files involved the
repository version after the update, the working file and the working
file's base revision. All three may have different settings for
svn:eol-style. Should the three way merge be attempted in repository
format or working copy format? If in working copy format, should each
file use it's own eol-style, or should they use a common eol-style?
If they use a common eol-style which one? What does the current
implementation do?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 21 03:28:18 2004