You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Szakmeister <jo...@szakmeister.net> on 2003/12/30 04:08:24 UTC
ghudson's 'svn st' problem he mentioned on IRC...
I don't know if anyone else looked at this, but ghudson mentioned that when he
did a 'cp -r' of his WC, all of a sudden some of the files in subversion/
bindings/com started showing up as being modified. I took a closer look, and
saw that the files that exhibit this property have their eol-style set to
CRLF. What I found out was that the text-base copy of the file didn't have
CRLF line endings... they were just plain LF. Just to double check, I create
a temp repository, shoved a few files in it, and toyed with changing the
eol-style, and every time after a commit, the text-base's line ending were
changed to match that of eol-style. I tried this using both ra_local and
ra_dav and got the same results. Simply touching SVN.rgs in subversion/
bindings/com causes 'svn st' to state that the file is modified... at least
on my Linux box.
So it seems we have a bit of a problem here (as ghudson eluded to on IRC). I
just wanted to post my finding just in case someone knew what the problem is
off the top of their head, or in case someone else was trying to track this
down.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ghudson's 'svn st' problem he mentioned on IRC...
Posted by kf...@collab.net.
> > I also went through the entire WC with the following script hunting for
> > differences in line endings. The only problem files I found were
> > the ones in subversion/bindings/com who had the svn:eol-style set to
> > CRLF. I really want to know what makes files different than others
> > who have the CRLF eol-style.
>
> Me too :-(.
Thinking out loud here:
One possibility is that there used to be a bug which caused the files
to be stored incorrectly (LF, say, instead of CRLF) even after the
svn:eol-style was set to CRLF. If our working copy code correctly
translates ("repairs") LF->CRLF, but is sensitive enough to *not*
convert CRLF->CRCRLF, then these old, wrongly stored files would still
get correct working files on the client side, but their text bases
would be messed up. Investigating...
Or: I thought maybe the propset was done via URL, so that the
repository storage never changed from LF to CRLF. But we don't
support propset on URLs, so that can't be it.
By the way, it looks like all these files got their svn:eol-style set
at the same time:
------------------------------------------------------------------------
r4369 | rassilon | 2003-01-13 15:56:53 -0600 (Mon, 13 Jan 2003) | 20 lines
* *.dsp: Set property svn:eol-style to CRLF.
* subversion.dsw: Set property svn:eol-style to CRLF.
* subversion/bindings/com/SVN.rgs: Set property svn:eol-style to CRLF.
* subversion/bindings/com/SVNCOM.idl: Set property svn:eol-style to CRLF.
* subversion/bindings/com/SVNCOM.rc: Set property svn:eol-style to CRLF.
* subversion/bindings/com/SVNStatus.rgs: Set property svn:eol-style to CRLF.
* subversion/bindings/com/SVNCOM.def: Set property svn:eol-style to CRLF.
* subversion/bindings/com/SVNCOMps.def: Set property svn:eol-style to CRLF.
* subversion/bindings/com/SVNCOMps.mk: Set property svn:eol-style to CRLF.
* subversion/bindings/com/resource.h: Set property svn:eol-style to CRLF.
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ghudson's 'svn st' problem he mentioned on IRC...
Posted by kf...@collab.net.
John Szakmeister <jo...@szakmeister.net> writes:
> I do remember there being some issues a while back with the line endings
> getting a bit confused. So that's why I checked out a fresh version of
> trunk/. It certainly seems like a current bug if the a fresh checkout
> doesn't have the correct line endings in the WC and text-base.
Yup... And I didn't try a fresh checkout w/ svn:eol-style props, just
updates. You'd think they'd behave the same, but then again, you'd
think there wouldn't be this bug in the first place. I'll try that.
> I also went through the entire WC with the following script hunting for
> differences in line endings. The only problem files I found were
> the ones in subversion/bindings/com who had the svn:eol-style set to
> CRLF. I really want to know what makes files different than others
> who have the CRLF eol-style.
Me too :-(.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ghudson's 'svn st' problem he mentioned on IRC...
Posted by John Szakmeister <jo...@szakmeister.net>.
On Monday 29 December 2003 23:14, kfogel@collab.net wrote:
> John Szakmeister <jo...@szakmeister.net> writes:
> > I don't know if anyone else looked at this, but ghudson mentioned that
> > when he did a 'cp -r' of his WC, all of a sudden some of the files in
> > subversion/ bindings/com started showing up as being modified. I took
> > a closer look, and saw that the files that exhibit this property have
> > their eol-style set to CRLF. What I found out was that the text-base
> > copy of the file didn't have CRLF line endings... they were just plain
> > LF. Just to double check, I create a temp repository, shoved a few
> > files in it, and toyed with changing the eol-style, and every time
> > after a commit, the text-base's line ending were changed to match that
> > of eol-style. I tried this using both ra_local and ra_dav and got the
> > same results. Simply touching SVN.rgs in subversion/ bindings/com
> > causes 'svn st' to state that the file is modified... at least on my
> > Linux box.
>
> Yeepers. Thanks for posting this...
>
> Okay, so to summarize: your experiment with the temp repository seems
> to show correct behavior -- the text bases should change, for
> hardcoded eol styles. On the other hand, touching 'SVN.rgs' in our
> tree shouldn't cause it to show up as modified. (And I just checked
> mine by hand: the working file has CRLF line endings, the
> svn:eol-style property is set to "CRLF", yet the text base is just LF
> endings. That's wrong.)
Yep, thats what I thought too. :-)
> This bug could be an old one that caused some working copy bogosity
> and then got fixed, or it could still be present in Subversion. Or,
> even if it doesn't show up in the committing working copy, it could be
> happening in working copies that receive eol-style changes via update.
I do remember there being some issues a while back with the line endings
getting a bit confused. So that's why I checked out a fresh version of
trunk/. It certainly seems like a current bug if the a fresh checkout
doesn't have the correct line endings in the WC and text-base.
> > So it seems we have a bit of a problem here (as ghudson eluded to on
> > IRC). I just wanted to post my finding just in case someone knew what
> > the problem is off the top of their head, or in case someone else was
> > trying to track this down.
>
> I'm trying to reproduce it, but so far this script doesn't reveal any
> bad behavior:
I tried the very same things and couldn't reproduce it either. I've even
tried dumping and loading repositories, but that didn't turn up anything
either.
I also went through the entire WC with the following script hunting for
differences in line endings. The only problem files I found were the ones in
subversion/bindings/com who had the svn:eol-style set to CRLF. I really want
to know what makes files different than others who have the CRLF eol-style.
-John
------
#!/usr/bin/env python
import os, filecmp, sys;
def check_ending(path):
#entries = os.listdir(path)
p = os.popen('svn ls -rBASE %s' % (path))
entries = p.read().splitlines()
p.close()
for x in entries:
if cmp(x, '.svn') != 0:
full_path = os.path.join(path, x)
if os.path.isfile(full_path):
text_base = os.path.join(path, '.svn', 'text-base', x +
'.svn-base')
a = get_line_ending(full_path)
b = get_line_ending(text_base)
if cmp(a, b) != 0:
print 'Line endings differ for %s (wc: %s, tb: %s)' % (full_path, a,
b)
else:
check_ending(full_path)
def get_line_ending(file):
f = open(file, mode='rb')
eol_found = False
prev = None
while not eol_found:
cur = f.read(1)
if cur == '':
break;
if cmp(cur, '\n') == 0:
eol_found = True
break
prev = cur
f.close()
if eol_found:
if cmp(prev, '\r') == 0:
return 'CRLF'
else:
return 'LF'
return None
check_ending('.')
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ghudson's 'svn st' problem he mentioned on IRC...
Posted by kf...@collab.net.
John Szakmeister <jo...@szakmeister.net> writes:
> I don't know if anyone else looked at this, but ghudson mentioned that
> when he did a 'cp -r' of his WC, all of a sudden some of the files in
> subversion/ bindings/com started showing up as being modified. I took
> a closer look, and saw that the files that exhibit this property have
> their eol-style set to CRLF. What I found out was that the text-base
> copy of the file didn't have CRLF line endings... they were just plain
> LF. Just to double check, I create a temp repository, shoved a few
> files in it, and toyed with changing the eol-style, and every time
> after a commit, the text-base's line ending were changed to match that
> of eol-style. I tried this using both ra_local and ra_dav and got the
> same results. Simply touching SVN.rgs in subversion/ bindings/com
> causes 'svn st' to state that the file is modified... at least on my
> Linux box.
Yeepers. Thanks for posting this...
Okay, so to summarize: your experiment with the temp repository seems
to show correct behavior -- the text bases should change, for
hardcoded eol styles. On the other hand, touching 'SVN.rgs' in our
tree shouldn't cause it to show up as modified. (And I just checked
mine by hand: the working file has CRLF line endings, the
svn:eol-style property is set to "CRLF", yet the text base is just LF
endings. That's wrong.)
This bug could be an old one that caused some working copy bogosity
and then got fixed, or it could still be present in Subversion. Or,
even if it doesn't show up in the committing working copy, it could be
happening in working copies that receive eol-style changes via update.
> So it seems we have a bit of a problem here (as ghudson eluded to on
> IRC). I just wanted to post my finding just in case someone knew what
> the problem is off the top of their head, or in case someone else was
> trying to track this down.
I'm trying to reproduce it, but so far this script doesn't reveal any
bad behavior:
#!/bin/sh
# Run this on a Unix (LF) system.
rm -rf repos wc wc2
svnadmin create repos
svn co file://`pwd`/repos wc
cd wc
echo "fish" > fish.txt
svn add fish.txt
svn ci -m "Adding fish.txt."
echo ""
echo "These ls's should report 5 bytes for each file:"
ls -l fish.txt .svn/text-base/fish.txt.svn-base
echo ""
cd ..
svn co file://`pwd`/repos wc2
cd wc2
echo ""
echo "These ls's should also report 5 bytes for each file:"
ls -l fish.txt .svn/text-base/fish.txt.svn-base
echo ""
cd ../wc
svn propset svn:eol-style CRLF fish.txt
svn ci -m "Committing CRLF eol-style for fish.txt."
echo ""
echo "These ls's should report 6 bytes for each file:"
ls -l fish.txt .svn/text-base/fish.txt.svn-base
echo ""
cd ../wc2
svn update
echo ""
echo "These ls's should also report 6 bytes for each file:"
ls -l fish.txt .svn/text-base/fish.txt.svn-base
echo ""
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org