Re: eol-style

[Russ Brown <pi...@gmail.com>]

On 5/26/05, Dale Worley <dw...@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

Re: eol-style

[stephen meechan <mg...@dsl.pipex.com>]

>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).
>
...
>
>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?

I have the same problem, at the time the SVN client (1.0.6, I think) let me
fix the files on the trunk by removing the property, fixing the file and
setting the property again. But later clients seem to have become more
strict about how they treat the inconsistencies and stop when they hit the
problem.

The problem today is usually when looking back in the history of the file,
is not possible to retrieve the old revision or diff against it to see what
was changing.

My thought is that is should be possible to dump the repository and check
for files with the property set but with lines that aren't normalized, then
create a new dump file with the repaired files and load that as the new
repository.


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

RE: eol-style

[Dale Worley <dw...@pingtel.com>]

> From: Russ Brown [mailto:pickscrape@gmail.com]
>
> 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?

You could probably do something like this:  Make a complete checkout.  Use
"svn propget -R svn:eol-style" to list all the files that have svn:eol-style
set, and the values.  Save that list.  Do "svn propdel -R svn:eol-style" to
remove all the eol-styles.  At this point your WC is OK.  Now massage that
list you made into a set of "svn propset svn:eol-style <value> <file>"
commands and execute them.  In the background, your client will edit the
EOLs on the files to make them consistent with the eol-styles you set, or at
least flag them as incorrect, which you can fix by hand or script.  Now
check the mess in.  That should make your repository consistent.

Dale


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