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

Re: ghudson's 'svn st' problem he mentioned on IRC...

From: John Szakmeister <john_at_szakmeister.net>
Date: 2003-12-30 13:55:00 CET

On Monday 29 December 2003 23:14, kfogel@collab.net wrote:
> John Szakmeister <john@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

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.


#!/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()

  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 +
        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,

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 == '':

    if cmp(cur, '\n') == 0:
      eol_found = True
    prev = cur

  if eol_found:
    if cmp(prev, '\r') == 0:
      return 'CRLF'
      return 'LF'

  return None


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 30 13:34:35 2003

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

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