It's all about the answers!

Ask a question

RTC 4.0.6 problems with line delimiters in automated checkin process

Thorsten Ferres (1367) | asked Apr 16 '14, 12:06 p.m.
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

permanent link
Michael Valenta (3.7k3) | answered Apr 16 '14, 3:58 p.m.
Have you tried the -n (or --delim-none) option? That should allow the checkin to proceed.

Thorsten Ferres commented Apr 28 '14, 10:43 a.m.

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:

Commit failed. Invalid line delimiter during checkin for:
  PATH/FILENAME1 (platform)
  PATH/FILENAME2 (platform)
Problem running 'checkin':

Shashikant Padur commented Apr 29 '14, 4:30 a.m.

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? 

Thorsten Ferres commented Apr 29 '14, 7:32 a.m.

Both files that show this problem existed already in the repository and have the following properties set:
Character Encoding: UTF-8
Executable: true
Line Delimiter: Platform
MIME Type: test/plain
Read Access: Public

I am trying to do the check-in on the following platform:

uname -a

Linux CLIENT HOSTNAME 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

and the RTC server is
$ uname -a
Linux SERVER HOSTNAME 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Dec 13 06:58:20 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

./ --version

Repo Tools
Provisioning using "./conf/jts/provision_profiles".
  Jazz Foundation - Core Libraries, Version 4.0.6 (RJF-I20140130-1407)

 To submit questions about issues, go to the forum at
 To find more information about a message, see the CLM Messages Information Center at
CRJAZ1363I Loading the configuration from "file:conf/jts/".

Thorsten Ferres commented Apr 29 '14, 7:35 a.m.

I am using the following version of the lscm command line tool:

lscm --version

Build Id: RTC-I20140205-1437, version 3.2.100.v20140114_0303
Provides Subcommands:
  list/streams, lastmod, set/flowtarget, get/change, undo/change,
  list/preferences, add/workitem, extract, list/daemons, workspace/unset,
  delete/workspace, set/property, create/component, set/user, annotate,
:, version 3.1.600.v20131218_0840
Provides Subcommands:
  tools.log, tools.validate, tools.generatehelp, tools.echo.stdin,
  tools.dump/postprocess, tools.dump, tools.verify, tools.configvalue, version 3.1.600.v20131217_0420
Provides Subcommands:

Thorsten Ferres commented Apr 29 '14, 7:53 a.m.

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.

Thorsten Ferres commented Apr 29 '14, 8:37 a.m.

But even after converting the affected files manually via dos2unix to the platform format, I still get the following error for a different file:
lscm checkin --delim-none all
Commit failed. Invalid encoding during checkin for:
Problem running 'checkin':

which also has the properties
Character Encoding: UTF-8
Executable: true
Line Delimiter: Platform
MIME Type: test/plain
Read Access: Public

Thorsten Ferres commented Apr 29 '14, 12:00 p.m.

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.
For my scenario where I need to be able to check-in lots of file revisions that are user-generated on various platforms I would require an option for the lscm-tool that would allow me to force the line delimiter to be set to 'none' and also ignore any character encoding.

sam detweiler commented Apr 29 '14, 12:13 p.m.

well, source is LINES of text. so you NEED a line end to differentiate the lines.

the ability to change the encoding is a known limitation.  particularly when u change the code to add some functional feature that forces it to change from ANSI to UTF-8, and there is no mechanism to support that.

I know my company two back had opened an enhancement request

showing 5 of 8 show 3 more comments

Your answer

Register or to post your answer.