Re: eol-style

On 5/26/05, Dale Worley <dworley@pingtel.com> wrote:
> > From: Russ Brown [mailto:pickscrape@gmail.com]
> >
> > Could this have anything to do with the fact that we imported our
> > repository from our original CVS one using cvs2svn? I think this is
> > the first working-copy commit on that file since the repository was
> > originally imported.
>
> It seems quite likely. But you should inquire as to how svn:eol-style got
> set without normalizing the stored EOLs.
>
> > This may also explain a number of large conflicts we've been getting.
> > Would this mean that every single file in the repository that has that
> > property set will appear to have been completely changed the first
> > time it is commited since the import?
>
> Quite possibly.
>
> You might be able to clean up the situation by doing a complete checkout and
> seeing if the client discovers that the EOLs are wrong for the eol-style and
> cleans them up in the WC. In that case, you want to check in the WC as
> quickly as possible, so people start working off a base with correct EOLs.
>
>

All,

Now that I understand what the problem is, I'd like some advice on how
to resolve it. It appears that the problem was caused by cvs2svn,
which imported Windows-formatted files with the svn:eol-style property
set but without normalising the endlines in the files themselves. This
affects all windows-formatted files in the system (primarily
templates).

The problem manifsts itself in two ways (that we're aware of):

1. If a user makes a change to the file and commits, it appears that
the entire file has changed. This appears to cause conflicts in all
merges that involve this changeset.
2. The file foils svn revert and causes it to die with a message like:

svn: File 'xxxxx/.svn/text-base/yyyyyy.svn-base' has inconsistent newlines

What I'm looking for is a way to correct the whole lot and commit the
fix in one big changeset. That will result in loads of conflicts in
the next few branch merges, but would fix the problem once and for all
going forward. The question is, how to do that. svn doesn't want to
commit the file unless the file gets changed, so I suspect that I'd
have to change the files in some way (though that is hardly ideal).
Anything else I can try?

The other problem is how to detect the problem files. The only way I
can think of is to look for all files that are Windows-formatted, have
the svn:eol-style property set to native, and haven't been changed
since the subversion import. Doesn't sound like a quick method (and
I'm not aware of a command-line utility to check for windows format).
Does anybody else have any suggestions?

Thanks.

-- 
Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org