"The problem is that the text-base in the repository has CRLF line endings.
This is an error."
I'm not clear on what this statement means: Did I do something
incorrect in setting up the repository or is there an error in Subversion?
I know how to find the text base in a working copy, under .svn,
but on the repository itself, I don't find a text-base but only
a strings file. This has a mix of printing and non-printing
ASCII and it does show, when viewed in hex, that there
is a CRLF for each line.
I have a repository of about 1.5 GB about to be used by several
people, and it is setup in the same why that I did testsvn. Thus
it is of importance to me to make a correction now if it is
possible.
Delbert Franz
On Friday 20 February 2004 06:28 pm, you wrote:
> "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 04:18:42 2004