MKS Source changes binary files automatically, how to prevent this?

[KaelLizak]

MKS Source changes binary files automatically, how to prevent this? (migrated thread) Posted: Dec 8, 2011 7:54 AM    andreas.ulbricht2     Posts: 47   Registered: Nov, 2007

We made the experience that MKS Source changes content of binary files, probably since we have upgraded to MKS2009 version. The change of the regarded binary files seems to be triggered by the archive type of these files, which is set automatically to text by the MKS source system. The workaround provided by MKS to prevent change of (binary) files after standard check in and check out actions consists of inclusion of the type of file characterized by the file extension into a policy. This is absolutely not practicable for us, as we cannot check any file by extension whether it is changed by the MKS system or not and include it in a policy. Furthermore the described behaviour is absolutely not what we expect from a version control system. We expect from a version control system that whatever file is put under version control, this file is NEVER changed automatically or non-transparently by the system. Does anyone know a method how we can prevent generally the automated change of whatever files by the MKS Source system ? Please be aware that the same can happen or happens on your MKS source system without that you notice it.

Re: MKS Source changes binary files automatically, how to prevent this? Posted: Dec 8, 2011 11:32 AM
Posted By:   mlizak     Posts: 72 /  Registered: Feb, 2011
Hello Andreas, Please contact Integrity Support so that we can assist you with this issue. Regards, Kael

Re: MKS Source changes binary files automatically, how to prevent this? Posted: Dec 9, 2011 12:27 PM Posted By:   mlizak     Posts: 72 /  Registered: Feb, 2011   Hello Andreas, Upon further research, I see that you have already contacted Integrity Support, and that you are already on the feature request, which I have resubmitted for review. Regards, Kael

Re: MKS Source changes binary files automatically, how to prevent this? Posted: Dec 16, 2011 3:35 AM Posted By:   andreas.ulbricht2     Posts: 47 /  Registered: Nov, 2007   Hello Kael, after several attempts to contact our key account for this subject, yesterday we had a TelCo with a senior supporter. After this conference our impression is that the problem is understood at MKS. A workaround that represents a solution for us could not be provided and in our understanding will not be provided until the RFC is implemented according to what we have understood in that TelCo. If an RFC is to be implemented and when this will happen is completely open. Anyway I do not understand why our key account or a substitute of him does not reply for two weeks when we have a major problem caused by MKS Source that endangers the delivery of our products. The addressed topic is crucial for us. If the problem cannot be solved, MKS Source might be useless as version management tool in our company. As support cannot provide a solution, any solution found by other users might be very helpful for us that's one reason why I post additionally here. I assume that the problem we have detected casually might be as crucial for a whole lot of other MKS customers as it is for us. But the other customers probably do not know about this problems, because they still do not have detected it. That`s another reason why I post here. Cheers !

Re: MKS Source changes binary files automatically, how to prevent this? Posted: Dec 20, 2011 4:15 AM Posted By:   markus.dittrich     Posts: 1 /  Registered: Feb, 2008   The initial description of the problem is not correct. The behavior is the same since a couple of releases. Binary Archive Files get's never changed by us. The Line Terminator get's changed for text archives depending on the policy which is set globaly / per project or per sandbox or defined for a specific type (f.e *.bin) or by a trigger. To prevent this the Users should be trained to check in Binary Files (f.e *.bin's) as binary archive and not as text archives. To prevent this there is a trigger which checks the extensions and could give a message that this archive which is going to be created by the user should be a binary archive instead of a text archive. In addition there is the possibility to update/change the archive from text to binary (on db-backend) to prevent this behavior with the line terminators. The algorithm checks every newly created archive as this is a text or a binary archive. It is not possible (never) to cover all files that this algorithm works as - depending on the customer- expected. There are a couple of possibilitys to prevent this behavior which is known since a long long time. We are currently working with you on a possible resolution for this behavior

Re: MKS Source changes binary files automatically, how to prevent this? Posted: Jan 18, 2012 3:37 AM Posted By:   becker     Posts: 13 /  Registered: Nov, 2010   Hi Andreas, we have the same issue with source files (ASCII) which we secure before check-in using file checksums. I agree that non-transparent changes of files should at least be made optional using appropriate server settings. This issue is considered critical for us as well. We started computing the checksums anew on check-out in our test automation. Files where the checksum differs from the stored value are reported as we need to make sure that changes are solely based on this whitespace issue and not due to other file manipulation. We strongly urge MKS to resolve this issue by at least making it optional using an appropriate server setting.

Re: MKS Source changes binary files automatically, how to prevent this? Posted: May 25, 2012 5:45 AM Posted By:   martin.bickel     Posts: 2 /  Registered: May, 2010   If you don't want files to be modified by MKS, why not always check them in as binary files? This can be configured through a policy si.AddMembers.dataFormat=binary To make diffs and merges, use an external like BeyondCompare or WinMerge. Keyword expansion is not possible with binary files, but that would be a modification of the file again, so I expect you want to avoid that anyway.

[khoppe]

For the danger of being off-topic:

1. In your files you may use variables that are identified as KEYWORDS in the Integrity-Context.
   When you are now using default-settings for some Source-commands like for eg. check in, you are using the functionality "expand keywords". Effect: your file will be changed during check in.
   Solution: define a general policy that uses the option "Unexpand keywords"
2. For existing text-archives you can define an archive-parameter "Store by reference".
   Doing this will have two effects:
   a. the internal "View Member Differences" won't work any longer.
   b. a check in won't store the difference to the previous revision any longer, but every time the complete file.
3. For the future you can define that every archive created will be a binary archive.
   Effects: see 2.

Hopefully this entry is helpful in your context.