.nch (namechange) file and version control

  • 3 March 2020
  • 4 replies
  • 224 views

Userlevel 3
  • AIMMS Implementation Partner
  • 22 replies

Hi there!

My question is fairly simple: how should we handle conflicts in the .nch file when merging different branches in a version control system?

When two branches originate from the same commit, and namechanges are made, the .nch file contains new lines at exaclty the same line numbers, often (always) resulting in conflicts. Currenlty I resolve these by resolving the conflicts with "mine before theirs” as I tend to want to keep both. The need for this (simple) manual intervention is a bit annoying.

What are the alternatives? Could we even simply ignore the .nch file in our git repository? Is there a way to track the file but prevent conflicts? I would like to hear your thoughts!


4 replies

Userlevel 5
Badge +2

I have the same “problem” and I resolve in the same way as you do.

Could we even simply ignore the .nch file in our git repository?

I don’t think so, because you would lose track to old cases (AIMMS .data files).

Userlevel 1
Badge

A similar issue has been discussed here before regarding merging of .json files. The solution for that was to sort entities in the webui.json file alphabetically.

So I am wondering if the same approach would work for .nch files?

Userlevel 3
Badge +3

The .nch file is used in several parts of AIMMS:

  1. Indeed: for cases. The most relevant now-a-days where most applications are WebUI based. Via the .nch file AIMMS knows how to map old names that are stored in a case onto the new names in the model.
  2. In the WinUI, for all references to identifiers stored in pages and user menus.
  3. Sometimes for libraries, which were readonly at the time the name change was done.

The best advice for handling the .nch file when multiple developers are working on the same model is:

  • Before committing: do a ‘commit namechanges’ in your model. This assures that WinUI and all (non-readonly) libraries are up-to-date with the latest namechanges. 
  • Check whether new entries in the name change file are relevant for any cases that may exist at the users of your model. For example, if the name changes only refer to newly created identifiers they are kind of redundant after the ‘commit namechanges’ command.
  • If you have a conflict: try to preserve the time stamp order.

Regarding the order of entries in the .nch file: 

For AIMMS the time stamps are relevant, and that is why these are used to order the .nch file. You can now read the .nch from top to bottom to see how identifiers have been renamed over time. Changing this only because of source control benefits does not seem the right thing to do.

 

 

Userlevel 2
Badge +4

If you use Git, then you can use the .gitattributes file to set the merge strategy to union. This basically automates the manual step you're currently doing (mine before theirs). The contents of the .gitattribute file should be: 

*.nch merge=union

 

Reply


Didn't find what you were looking for? Try searching on our documentation pages:

AIMMS Developer & PRO | AIMMS How-To | AIMMS SC Navigator