You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Damian Sinclair <Da...@homechoice.net> on 2007/02/01 09:40:33 UTC
RE: Odd Conflicts (EOL issues) in repo converted from VSS
> 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?
Damian Sinclair
=======================================================================
Homechoice is a trading name of Video Networks Limited of 205 Holland Park Avenue, London W11 4XB and registered in England and Wales (No. 2740910).
This email may contain confidential and privileged information and is intended for the named or authorised recipients only. If you are not the named or authorised recipient of this email, please note that any copying, distribution, disclosure or use of its contents is strictly prohibited. If you have received this email in error please notify the sender immediately and then destroy it. The views expressed in this email are not necessarily those held by Video Networks Limited and we do not accept any liability for any action taken in reliance on the contents of this message. We do not guarantee that the integrity of this email has been maintained, nor that it is free of viruses, interceptions or interference.
_______________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs Email Security System.
_______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
[RESOLVED] RE: Odd Conflicts (EOL issues) in repo converted from VSS
Posted by Damian Sinclair <Da...@homechoice.net>.
> How insane would it be to attempt to change the eols
> in a dump file? From a quick look it seems like all I'd need
> to do is strip the CR characters and rewrite the text-length
> and md5 checksums. Am I being naïve or would this not produce
> a fully working repo with all history intact?
Just a note to the list to state that I hacked together a Python script to do exactly this and the new and the new repository seems to be working fine. It still seems a rather drastic and risky way of fixing matters, but working is working.
Thanks to Jeff and Toby for their input.
Damian Sinclair
=======================================================================
Homechoice is a trading name of Video Networks Limited of 205 Holland Park Avenue, London W11 4XB and registered in England and Wales (No. 2740910).
This email may contain confidential and privileged information and is intended for the named or authorised recipients only. If you are not the named or authorised recipient of this email, please note that any copying, distribution, disclosure or use of its contents is strictly prohibited. If you have received this email in error please notify the sender immediately and then destroy it. The views expressed in this email are not necessarily those held by Video Networks Limited and we do not accept any liability for any action taken in reliance on the contents of this message. We do not guarantee that the integrity of this email has been maintained, nor that it is free of viruses, interceptions or interference.
_______________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs Email Security System.
_______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Odd Conflicts (EOL issues) in repo converted from VSS
Posted by Toby Johnson <to...@etjohnson.us>.
Damian Sinclair wrote:
>> -----Original Message-----
>> From: Jeff Smith [mailto:jsmith@robotronics.com]
>>
>
>
>> If that didn't work, I'd probably try 'export' the tree and 'import'
>> to an empty repos. I'd actually expect the dump/load to be
>> better at preserving the problem your having, else I couldn't
>> trust it when the files were binary, and needed not to be converted.
>>
>
> I suspect you're right on the dump and load behaviour, the eols are certianly preserved in the dump file itself. Won't I lose the entire history if I do an export and import though?
>
> How insane would it be to attempt to change the eols in a dump file? From a quick look it seems like all I'd need to do is strip the CR characters and rewrite the text-length and md5 checksums. Am I being naïve or would this not produce a fully working repo with all history intact?
>
What you're describing (fix EOLs, set checksums and text-length) should
work fine. The dumpfile was designed to be a rather simple and
platform-independent format.
toby
RE: Re: Odd Conflicts (EOL issues) in repo converted from VSS
Posted by Damian Sinclair <Da...@homechoice.net>.
> -----Original Message-----
> From: Jeff Smith [mailto:jsmith@robotronics.com]
> If that didn't work, I'd probably try 'export' the tree and 'import'
> to an empty repos. I'd actually expect the dump/load to be
> better at preserving the problem your having, else I couldn't
> trust it when the files were binary, and needed not to be converted.
I suspect you're right on the dump and load behaviour, the eols are certianly preserved in the dump file itself. Won't I lose the entire history if I do an export and import though?
How insane would it be to attempt to change the eols in a dump file? From a quick look it seems like all I'd need to do is strip the CR characters and rewrite the text-length and md5 checksums. Am I being naïve or would this not produce a fully working repo with all history intact?
Damian Sinclair
=======================================================================
Homechoice is a trading name of Video Networks Limited of 205 Holland Park Avenue, London W11 4XB and registered in England and Wales (No. 2740910).
This email may contain confidential and privileged information and is intended for the named or authorised recipients only. If you are not the named or authorised recipient of this email, please note that any copying, distribution, disclosure or use of its contents is strictly prohibited. If you have received this email in error please notify the sender immediately and then destroy it. The views expressed in this email are not necessarily those held by Video Networks Limited and we do not accept any liability for any action taken in reliance on the contents of this message. We do not guarantee that the integrity of this email has been maintained, nor that it is free of viruses, interceptions or interference.
_______________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs Email Security System.
_______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Odd Conflicts (EOL issues) in repo converted from VSS
Posted by Jeff Smith <js...@robotronics.com>.
On Thursday 01 February 2007 07:45, Toby Johnson wrote:
> #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 didn't work, I'd probably try 'export' the tree and 'import'
to an empty repos. I'd actually expect the dump/load to be better at
preserving the problem your having, else I couldn't trust it when the
files were binary, and needed not to be converted.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Odd Conflicts (EOL issues) in repo converted from VSS
Posted by Toby Johnson <to...@etjohnson.us>.
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