[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