Hi David et al.,
On Mon, Jul 12, 2010 at 10:58 PM, Kitching, Simon
> > We've got a repository containing a lot of text-files committed from windows
> > systems without the svn:eol-style=native setting. Some developers now want
> > to work on these from Linux.
> >
> >
> >
> > I would therefore like to fix the eol-style. Writing a script on linux to
> > find all the relevant files and run propset svn:eol-style native on them
> > is easy enough. However I've noticed that if the change is committed from
> > *linux*, then the commit not only changes the file properties, but also
> > *every line-ending in the file*, ie looking at diffs between files before
> > and after this change is now pointless. Committing exactly the same propset
> > change from *windows* just sets the property without the whitespace
> > problems; checking out on both systems then works as expected, and diffs
> > between repository versions are sane.
> >
> >
> >
> > However it's much more convenient to write and run this script from linux.
> > Is there any way from linux to persuade subversion to just set the eol-style
> > property?
> >
>
On Wed, 2010-07-14 at 10:35 -0400, David Weintraub wrote:
> I have a pre-commit hook that will verify that particular files have
> svn:eol-style set before allowing a commit. This way, you can make
> sure that the property is set before anyone can do a commit.
Yes, that might be the best way to prevent the problem reoccurring in
the future. Unfortunately, it doesn't help with fixing a pre-existing
repository (ie setting eol:style=native on existing files that really
should have had it set when they were created but didn't).
>
> What IDE are you using? If you're not using an IDE, what program
> editor are you using. Please, tell me, for the sake of everything we
> hold dear, that your developers aren't using Notepad for editing their
> files. Please tell me they're not.
No, developers here are using Eclipse on Windows or Eclipse on Linux.
>
> Your developers on your Windows side need a good program editor. A
> good program editor handles various line endings with aplomb. That
> means it doesn't matter if a file has either Windows or Unix style
> line endings. The text editor will handle that and there is no need to
> convert from one to the other. In fact, your Linux developers should
> also be working with a similar editor.
The problem is not tools handling different line-endings. The problem is
that (without eol-style=native) all text files end up with a nasty mix
of line-endings; files added by devs using Windows have lines ending in
\r\n and files added by devs using linux have lines end in \n. It's not
the end of the world, but it's just not right.
Interestingly, Eclipse is smart enough to detect line-endings for
preexisting files, and uses the same line-ending style when editing that
file. But new files get the local OS defaults.
The correct answer is to set eol-style=native on the relevant files. But
SVN appears to have some weird behaviour that makes adding this property
to existing files much more difficult than it should be. AFAICT it is
only possible to *correctly* fix this issue from a Windows PC!
I've double-checked: setting svn:eol-style=native on all the relevant
files and then committing from windows works well. The history diffs
show just a property change, as expected. Unfortunately, writing scripts
on Windows to scan a directory and set the property isn't so easy (at
least for me); "find .. -exec svn propset ..." isn't an option :-(
And doing a find/exec + commit on linux to fix the problem causes
historical diffs to show that every line has changed :-(
Ah well, as it appears that nobody here knows the answer I'll just have
to do it the ugly way: try to get the svn repo administrator to install
some hooks to prevent this occurring in future, and then install cygwin
on somebody's windows PC to script the adding of eol-style=native to
relevant existing files.
> This gives me a visual diff, and I call it via:
>
> $ svn diff --diff-cmd mydiff <file>
>
> Here's what mydiff looks like:
>
> #! /usr/bin/env perl
>
> use strict;
> use warnings;
>
> my $DIFF = "/usr/bin/vimdiff";
>
> my $parameters = $#ARGV;
> my $file1 = $ARGV[$parameters - 1];
> my $file2 = $ARGV[$parameters];
> my $title1 = $ARGV[$parameters - 4];
> my $title2 = $ARGV[$parameters - 2];
>
> my $title = "$title1 - $title2";
> $title =~ s/\t/ /g;
> $title =~ s/ /\\ /g;
> my $command = qq($DIFF -c "set titlestring=$title" "$file1" "$file2");
> system qq($command);
>
>
Yes, that will suppress the whitespace output for users who use this
special diff-command, but won't help those looking at diffs via
tortoise-svn for example. And it's only hiding the problem, not really
fixing it. It would be better for svn to correctly recognise that the
only diff in the commit really is a property-change.
David, thanks for taking the time to reply. I appreciate it.
Unfortunately, none of the suggested solutions works for my environment.
Maybe I'll raise a bugreport for this - though I doubt it will get high
priority. Still, there must be a reasonable number of places like mine
where developers working on a large pre-existing codebase are slowly
migrating from windows to linux desktops.
Regards,
Simon
Good planets are hard to find - please think of the environment before you print this email.
____________________________________________________________________
CAUTION - This message may contain privileged and confidential
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby
notified that any use, dissemination, distribution or reproduction
of this message is prohibited. If you have received this message in
error please notify Air New Zealand immediately. Any views expressed
in this message are those of the individual sender and may not
necessarily reflect the views of Air New Zealand.
_____________________________________________________________________
For more information on the Air New Zealand Group, visit us online
at http://www.airnewzealand.com
_____________________________________________________________________
Received on 2010-07-20 05:12:11 CEST