[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Setting svn:eol-style

From: Juanma Barranquero <jmbarranquero_at_wke.es>
Date: 2003-12-04 16:04:52 CET

[First of all, sorry if alternate versions of this message appear on the
list sooner or later; I sent a previous attempt from home, but my ISP is
acting weird all week. To make things even easier, my work's e-mail
address has changed and I've had to resubscribe, so anything's posible,
from this message never reaching users@subversions.tigris.org to ending
with three or more copies :) ]

On 03 Dec 2003 14:19:47 -0600
"C. Michael Pilato" <cmpilato@collab.net> wrote:

> You (and all your developers) could set up auto-props to set the
> property on known text-file patterns (*.c, *.h, *.txt, etc.). At
> least, I think you can -- I've not gotten around to trying the
> auto-props stuff for myself.

IMHO, the interaction auto-props / svn:eol-style does produce some
un-intuitive behaviour, at least on Windows.

The "problem" does show when you import a CRLF-delimited file matching
an auto-prop rule which applies the svn:eol-style=native property (in my
example, I have one such rule for *.c). The symptom is that, immediately
after the import, a checkout of the file shows it as modified, so you
have to re-commit it. Afterwards it works OK. No doubt the same problem
would happen if you import a LF-delimited file with a svn:eol-style=CRLF
rule, but I haven't tested that.

Without looking at the source code, that's what I think is happening:

 - The file is imported as is (i.e., with CRLF).
 - The auto-prop is set on the file (*after* it being copied to the
   repository)
 - On checkout, the .svn/text-base/ copy of the file has CRLF (as it is
   an exact copy of what was imported). The file of course has CRLF too.
 - "svn status" sees that the file has svn:eol-style=native, so in order
   to compare it with the base copy, turns it into native (LF) style.
 - Obviously, foo.c and .svn/text-base/foo.c.svn-base are *not* equal
   now, so "svn diff" shows that every line is changed.
 - Recommitting the file modifies .svn/text-base/foo.c.svn-base so it now
   has native endings (because the client knows that's what the server
   will have).
 - From that moment on, everything's OK.

If my analysis is right, the problem can be traced back to the fact that
a file is copied into the repository with line endings which do not
match its svn:eol-style property (because the style was set afterwards).
In such case, the answer would be to force that, on importing, files
matching auto-props with svn:eol-style properties are converted to the
appropriate style *before* copying them into the repository.

If I'm completely wrong and/or what I'm seeing is the expected behaviour,
sorry for the noise :)

An example session:

D:\> svnadmin create mytest

D:\> cd mydata

D:\mydata> dir

 Volume in drive D is Pincho Serial number is 14A8:63AE
 Directory of D:\mydata\*

 4/12/2003 11:14 15 foo.c
             15 bytes in 1 file and 0 dirs 4.096 bytes allocated
  8.477.417.472 bytes free

D:\mydata> type foo.c
int main() {}

D:\mydata> od --format=x1 foo.c
0000000 69 6e 74 20 6d 61 69 6e 28 29 20 7b 7d 0d 0a
0000017

D:\mydata> svn import -m "Test." file:///D:/mytest/testdir
Adding foo.c

Committed revision 1.

D:\mydata> del foo.c
Deleting D:\mydata\foo.c
     1 file deleted

D:\mydata> cd ..

D:\> svn co file:///D:/mytest/testdir mydata
A mydata\foo.c
Checked out revision 1.

D:\> cd mydata

D:\mydata> svn status
M foo.c

D:\mydata> od --format=x1 foo.c
0000000 69 6e 74 20 6d 61 69 6e 28 29 20 7b 7d 0d 0a
0000017

D:\mydata> od --format=x1 .svn\text-base\foo.c.svn-base
0000000 69 6e 74 20 6d 61 69 6e 28 29 20 7b 7d 0d 0a
0000017

D:\mydata> svn commit -m "Fix after auto-prop."
Sending foo.c
Transmitting file data .
Committed revision 2.

D:\mydata> od --format=x1 .svn\text-base\foo.c.svn-base
0000000 69 6e 74 20 6d 61 69 6e 28 29 20 7b 7d 0a
0000016

D:\mydata> svn status

D:\mydata>

                                                                Juanma

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 4 16:06:25 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.