We are using ClearCase UCM INTEROP setup in our organization.
We are facing a strange issue where the file content in put on one line while doing a merge and hence causing the build to fail.
Does anyone know why this is happening?
There is another thing that can sneak up and bite you here.
View text modes -- there are 3 for ClearCase, and you can get unexpected results if you use the wrong 2.
Those modes are:
insert_cr (also known as msdos). This inserts carriage returns on cleartext creation (file open/edit/etc.) and strips them at checkin.
transparent. Doesn't make any changes to the line terminations.
strip_cr. This converts Windows line terminations to Unix ones on cleartext creation. It then re-inserts them on checkin.
If you use strip_cr for unix views, and insert_cr for Windows ones, you will have all kinds of line termination issues. And in some cases this can break builds.
You need to use the 2 that are adjacent to one another on the list above. With Windows using either insert_cr and unix "transparent". Or Windows "transparent" and unix strip_cr.
You may want to look at the problem file in another editor (notepad++ is one that handles both line termination styles well) and see whether you have Unix or Windows line terminations.
It would also help to know the platform where the merge was attempted. If it was done on Windows, then #VoC's steps will work as they call the Windows GUI text merge tool. You may want to try the same thing using the Windows/Unix CLI merge tool (cleardiff) if the files are "text_file" elements. We have seen cases where the 2 CLI and GUI merge tools behave differently.
It depends on:
what "put on one line while doing a merge" means (extra line added, or the all text is in one line, which would mean \n isn't treated as a newline character)
the type of file being merge (text, xml, binary, ...), as the merge manager involved would differ.
Start by trying to reproduce the issue, as explained in this technote:
Copy the "base" version into base.txt.
Copy the "from" version into from.txt and copy the "to" version into to.txt.
Run the following command:
cleardiffmrg -out foo.out -base base.txt from.txt to.txt
See if ignoring whitespaces helps:
cleardiffmrg -blank_ignore -out foo.out -base base.txt from.txt to.txt.
Check your text modes associated with the view in which you are doing the merge.
Try and make sure the newline sequence used in both versions of the file is the same (\n for instance, both in Windows and Unix)
Related
Why do I have to manually for every file change "CRLF" to "LF" to make eslint(prettier) warning go away?.
Can there be a problem with this approach when committing and other users load the file in their respective environment. As you see on the image I get "eslint": "^6.6.0" complaint and when I toggle the down right "CRLF" to "LF" then eslint(prettier) is happy.
Can this be a problem later?
Line breaks are traditionally represented by two bytes (CR and LF) on DOS/Windows systems, and by only one (LF) on Unix/Linux systems. The rule you're seeing, documented for eslint here and for prettier here defaults to saying that all files should use the Unix convention (saying "delete CR" is equivalent to saying "convert CRLF to LF only") to ensure the code base is consistent.
If all your files are currently CRLF, you have two options:
Configure eslint/prettier to standardise on "crlf" / "windows" instead (or disable the rule completely).
Change the line endings on your files from CRLF to LF. That could be file by file using the setting you show, by running a command-line tool like dos2unix, or by configuring prettier to fix the problem automatically.
As well as fixing your existing files, you might want to look at why they're showing up that way:
Ensure VSCode is configured to create new files with Unix / LF line endings by default
git has a "feature" that by default checkouts created on Windows will convert LF to CRLF every time you checkout, and convert them back when you commit. Since any decent code editor will cope with LF line endings just fine (even Notepad supports them now!) you should turn this off with git config core.autocrlf false
As for how this will affect other people:
If you change the line endings of files in a shared repo, this will show up as a change to every line in the version history. This is mostly a one-off nuisance, and creates a bit of noise when you're looking at the history of a file.
In the unlikely scenario someone's opening the file in a tool that only supports CRLF line endings, they'll have problems opening it. They can work around it with the above-mentioned core.autocrlf setting, or by using a better tool.
Even if the output files of a Snakemake build already exist, Snakemake wants to rerun my entire pipeline only because I have modified one of the first input or intermediary output files.
I figured this out by doing a Snakemake dry run with -n which gave the following report for updated input file:
Reason: Updated input files: input-data.csv
and this message for update intermediary files
reason: Input files updated by another job: intermediary-output.csv
How can I force Snakemake to ignore the file update?
You can use the option --touch to mark them up to date:
--touch, -t
Touch output files (mark them up to date without
really changing them) instead of running their
commands. This is used to pretend that the rules were
executed, in order to fool future invocations of
snakemake. Fails if a file does not yet exist.
Beware that this will touch all your files and thus modify the timestamps to put them back in order.
In addition to Eric's answer, see also the ancient flag to ignore timestamps on input files.
Also note that the Unix command touch can be used to modify the timestamp of an existing file and make it appear older than it actually is:
touch --date='2004-12-31 12:00:00' foo.txt
ls -l foo.txt
-rw-rw-r-- 1 db291g db291g 0 Dec 31 2004 foo.txt
In case --touch (with --force, --forceall or --forcerun as the official documentation says that needs to be used in order to force the "touch" if doesn't work by itself) didn't work out as expected, ancient is not an option or it would need to modify too much from the workflow file, or you faced https://github.com/snakemake/snakemake/issues/823 (that's what happened to me when I tried --force and --force*), here is what I did to solve this solution:
I noticed that there were jobs that shouldn't be running since I put files in the expected paths.
I identified the input and output files of the rules that I didn't want to run.
In the order of the rules that were being executed and I didn't want to, I executed touch on the input files and, after, on the output files (taking into account the order of the rules!).
That's it. Since now the timestamp is updated according the rules order and according the input and output files, snakemake will not detect any "updated" files.
This is the manual method, and I think is the last option if the methods mentioned by the rest of people don't work or they are not an option somehow.
I have a text file in clearcase (unix) When i open it on my windows clearcase client side the carriage returns are just fine. However when i run the build and open after it has been checked in and labeled and packaged the carriage returns are removed. If i open the file in unix the ^M is at the end of the file. I have tried removing them but they come right back. I have tried dos 2 unix in a new file but same result. right now i am going to try and create a new view but sure what tmode. Here is what i use and i have to make the view on unix.
cleartool mkview -tag view_name -tmode insert_cr -ncaexported ./view_name.vws
Thanks for your help!
Regarding tmode, see "About text modes for views".
I really prefer "transparent": No line terminator processing is done.
Then, if you still see changes after build, you know this is not ClearCase doing, but potentially your build process that might change the eol style (end of line, with their carriage returns).
I'm trying to write a makefile to replace one of the scripts used in building a fairly large application.
The current script compiles one file at a time, and the primary reason for using make is to parallelise the build process. Using make -j 16 I currently get a factor of 4 speedup on our office server.
But what I've lost is some readability of the output. The compilation program for a file bundles up a few bits and pieces of work, including running custom pre-compilers, and running the gcc command. Each of these steps outputs some information, and I would prefer it to buffer the output from the command, and then show the whole lot in one go.
Is it possible to make make do this?
If you upgrade to GNU make 4.0, then you can use the built-in output synchronization feature to get what you want.
If you don't want to upgrade, then you'll have to modify each of your recipes to be wrapped with a small program that manages the output. Or you can set the SHELL variable to something that does it for you. Searching the internet should give you some examples.
A simple way to accomplish this is to send all the log output a to log directory with each file named, say:
log_file_20131104_12013478_b.txt // log_file_<date>_<time>_<sequence letter>.txt
and then simply cat them all together as your last make job in the dependency chain:
cat log_dir/log_file_20131104_12013478_*.txt > log_file_20131104_12013478.txt
With makepp this is the default behaviour as soon as you use -j. All the individual outputs (and entering dir messages) get collected and are output together as soon as the command terminates.
I am getting some weird characters at the end of some of my files.
The files are not checked out when this occurs and if I check them out and undo the check-outs these characters disappear.
The problem is it does this with files at random, not the same ones all the time, but a number of files here and there. One of the consequenses of these occurances is that eclipse projects cannot be loaded since the .project-file is seen as corrupt. Any suggestions as to why this happens?
I am sorry I cannot post any images. However, in text shown in notepad++ it is written as:
....
....
<last_line>[nul][nul][nul][nul][nul][nul][nul]...
by the way, [nul] has the value 0x00.
It could be an encoding issue, like one described in this technote, where Diffmerge incorrectly selects encoding based on locale.
You can check their encoding by editing them in Notepad++.
Check also your ClearCase Unicode Type Manager.
Depending on your ClearCase version, you also had issue with the magic file.
Finally, check if you have some corrupt container associated with those files:
See technote swg21222072 Type manager text_file_delta failed create_version operation.