RTC 4.0.6 problems with line delimiters in automated checkin process
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
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:
Commit failed. Invalid line delimiter during checkin for:
PATH/FILENAME1 (platform)
PATH/FILENAME2 (platform)
Problem running 'checkin':
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:
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
./repotools-jts.sh --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 Jazz.net forum at https://jazz.net/forum.
To find more information about a message, see the CLM Messages Information Center at
https://jazz.net/help-dev/CLMErrorMessages/index.jsp.
CRJAZ1363I Loading the configuration from "file:conf/jts/teamserver.properties".
4.0.6
I am using the following version of the lscm command line tool:
lscm --version
Build Id: RTC-I20140205-1437
com.ibm.team.filesystem.cli.client, 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,
:
:
com.ibm.team.filesystem.cli.tools, 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
com.ibm.team.rtc.cli.infrastructure, version 3.1.600.v20131217_0420
Provides Subcommands:
help
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:
lscm checkin --delim-none all
Commit failed. Invalid encoding during checkin for:
PATH/FILENAME (UTF-8)
Problem running 'checkin':
which also has the properties
Character Encoding: UTF-8
Executable: true
Line Delimiter: Platform
MIME Type: test/plain
Read Access: Public
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.
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
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=216552