RTC 4.0.6 problems with line delimiters in automated checkin process
I try to import files from an existing cvs repository checked in from different platforms (Linux, Windows, maybe even MAC or AIX) using the command
lscm checkin but when I use the option lscm checkin -n PATH I get the error Commit failed. Invalid line delimiter during checkin for: PATH/FILENAME1 (platform) PATH/FILENAME2 (platform) PATH/FILENAME3 (platform) Problem running 'checkin': Unable to checkin due to invalid file encoding or line delimiter. and when I use the option lscm checkin -C PATH I get the error File PATH/FILENAME has character encoding UTF-8 but the contents do not match the encoding. Change the encoding of the file. <Remote exception was of type 'java.nio.charset.MalformedInputException'> Input length = 1 Change is not a deletion: CONTENT /all/se/hom/pku/ypkupackagingunit.cpp [UUID _a1COccPnEeO4U5Y67Xu2qQ] Problem running 'checkin': Errors encountered during Check-in The content of the files can not be changed to have common line delimiters or a common file encoding because this is an automated process which should run unattended. Is there no way to just ignore the line delimiters and file encoding during lscm checkin and just check in the content of a file as is? Or is this a feature RTC can not handle yet and I need to open a PMR? |
One answer
Have you tried the -n (or --delim-none) option? That should allow the checkin to proceed.
Comments As mentioned above, I already used the -n option and now I also tried the long version of this option (--delim-none), but got the same result:
Is this a new file or was there already a file in the repository that had the line delimiter set to platform? and on which OS did you encounter this error? Both files that show this problem existed already in the repository and have the following properties set:
uname -a
./repotools-jts.sh --version
I am using the following version of the lscm command line tool:
lscm --version
I finally edited the affected versions (with vi, less or gedit seem to ignore special characters) of those files and found out that they seem to contain a carriage return character (^M, 0xD) at the end of each line all of sudden - I guess they must have been generated on a Windows platform and checked into the cvs repository without conversion of the end-of-line character.
But even after converting the affected files manually via dos2unix to the platform format, I still get the following error for a different file:
As far as I understand now the lscm-tool first checks if it can find out the line delimiter and character encoding automatically, so even the option -n (or --delim-none) does not force the tool to ignore any line delimiter and character encoding and just check-in the a file as is (i.e. binary), only if the tool has problems finding out line delimiter and character encoding automatically, it will ignore them when this option is used. It is also unable to handle changes in the values for the line delimiter or character encoding used. So if a file has been checked-in first with a platform line delimiter and UTF-8 encoding, lscm does not try to change those values if the content of a new revision for this file has changed in a way that would require to change the line delimiter or the character encoding used so far.
well, source is LINES of text. so you NEED a line end to differentiate the lines.
showing 5 of 8
show 3 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.