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

Re: Annotate broken on trunk on Win32

From: D.J. Heap <djheap_at_gmail.com>
Date: 2006-02-10 15:40:37 CET

On 2/10/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
[snip]
> > Some of the files in Subversion's repository (build.conf, for example)
> > show slightly different blame output on Win32 vs Linux, but I think
> > that's to be expected given the history of the client and server code
> > that has built that particular repository. It is working perfectly on
> > the test repositories I've been using.
> >
>
> Huh. Could you show us what you mean? Is it just that the translation
> code is hiding inconsistent newlines (and so we're seeing less changes
> on win32), or is it something more serious?

Yes, that is what I was thinking -- inconsistent newlines due to bugs
in the eol handling or mixed newlines being commited before the
eol-style was set or something. But after playing with it more, I
don't think that is happending.

If a file is added with no eol-style and then sometime later has an
eol-style set to 'native', then it may show different blame output on
different platforms. The original file had the newlines of it's
original platform and so blame works 'normally' -- but on a different
platform the revision *after* the eol-style change will get credit for
all the lines.

For example, on Win32 a blame of build.conf shows the first 3 lines
credited to '4387 striker' but on Linux they are '1 svn'. The
eol-style was changed to 'native' in r4371 which was the only change
to build.conf until r4387.

But if I add a file on Linux with no eol-style, make a few changes,
then later set the eol-style to 'CRLF', the diff will show every line
changed in that commit (as well as the eol-style change) and so blame
credits that revision with every line.

Kind of odd, but reasonable, I guess, given how eol-style handling
works. And with the new 'ignore eol' option it could be easily worked
around if needed.

DJ

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 10 15:42:36 2006

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.