Damian Sinclair wrote:
>> Yes, I think you're correct, the text-base seems to always
>> contain the LF eol. So you're saying that once a file has
>> been committed once, it behaves correctly thereafter? In that
>> case then I would agree that it sounds like a problem with
>> the import. I'm not sure how the Polarion tool works so it is
>> possible that it imported the file as CRLF instead of LF
>> which is now causing the problem.
>>
>
>
> Good, I'm glad my thinking isn't entirely faulty. Thanks for your time
> on this.
>
> Now, this leaves me with how to resolve the problem.
>
> 1/ Some form of subversion magic that converts the files internally.
>
> 2/ Some method of forcing a commit without any change having occurred
> so that the file gets reconverted. Can I just touch the files?
>
> 3/ Adding a whitespace change to every file and committing.
>
> Any recommendations?
>
I'm assuming that means the answer to my question is affirmative; the
files work correctly after they're committed once. So as far as your
choices:
#1 I wouldn't try any sort of "Subversion magic" but you might find that
a dump and reload of your repo fixes the problem (I believe you can pipe
"svnadmin dump" and "svnadmin load" together directly, loading to a new
repo). If that doesn't work you may be able to create a dumpfile and
then manipulate it using a script to fix the endings, but that of course
would be quite a bit more involved.
#2 You could probably accomplish this by removing all svn:eol-style
properties, committing them, then reapplying the property and committing
them again.
#3 Also certainly possible but I think if #2 works it would be the
better choice.
The downside to #3 and maybe #2 are that it will cause whoever performs
those commits to "touch" every line of every file, rendering Blame
information less informative for prior revisions. That may or may not be
a concern to you.
toby
Received on Thu Feb 1 15:39:16 2007