Using Git to version Microsoft Dynamics NAV?

Question

I'm a .NET developer, but in our organization we also have a couple of Microsoft Dynamics NAV developers. Currently they're not using any source control. I know very little about NAV, but as I understand it, you can script out objects from NAV and import back in from the scripts.

That being the case, is anyone using Git with NAV? Have you run into any gotchas along the way? I'm wondering if this is a good solution to suggest to them, and whether it's any more complicated to manage than using Git with .NET (which I've found reasonably easy).

Answer 1

Yes we are using Git together with Dynamics NAV with great success!

The bad thing is that all objects must be exported to txt before Git gives meaning. Let's hope that Microsoft will create an easier approach to exporting objects to txt. We are using this model. Create a Git repository with a general master, and a branch for each object we change. All source files must have the same name as the branch top file to make Git track differences. Using Git in this way, we never merge anything into master. After starting using Git it's much easier to work on shared objects and track what other NSC's have done with the code. And IT-Revision is happy because all code is well documented and the way to any fallback is much easier. I'll give my full endorsement to use Git with Dynamics NAV.

Navision Consultant, in Oil & Energy Industry

Answer 2

I'm using Dynamics NAV and Git, however not at the same time. Let me explain why.

The Git itself is cool (with GitHub it gets even better), but the Windows port is poor, unless you don't like to stick to unix-like command line, since it's the recommended way to setup msysGit. The GUI tools on Windows are no good, unfortunately.

For me it was hard to make my boss understand, why using distributed version control is better than the usual TFS. For business-oriented guys one big central repository feels more secure (because it's my own server I pay for, I control access to) and more robust (I hired a system administrator who will run maintenance procedures).

I decided not to fight against this will. We're using distributed version control as a staging area. All unstable changes are stored in this area and we do testing within our team. After finishing stabilization, objects are merged into the central repository. Everybody looks happy.

Regarding Git: Recently I switched to another distributed version control — fossil due to following reasons:

• It can do everything that Git can;
• It looks, feels and acts native on Windows;
• It has a web-interface build-in and I can easily make it run as a native Windows service;
• It has integrated issue-tracking, so I don't need third-party tools any more;
• The Repository is a single file, so I can take it with me on a pen drive everywhere I want;

Regarding our NAV solution. It's more than 1000 objects, size over 20 MB.

EDIT: Some updates after more than half year of coding.

We switched back to git. Since its automatic merge is AWESOME. Just to win the bet I've moved a solution (modified standard objects and new ones) from NAV7CTP3 to NAV7CTP5 in 4 hours. While a team of four developers achieved the same result needing almost three weeks of everyday work.

Git really makes a difference. I believe the same results are possible with other distributed version control systems.

The reason is: Git and other distributed systems save a lot more information during a commit than i.e. TFS and SVN. It is not so important during regular development, but when it comes to merging, all this 'redundant' information from Git makes the difference.

During the merge Git finds the common revision which started a branch and then applies changes from both branches step by step - in the same way as the developer changed the code - to all files in solution.

If the same line was changed in both branches it shows the conflict. If not it just saves the files into the working folder ready for commit.

Here some statistics:

• The Total number of files processed in both CTP3 and CTP3 codebases is around four thousand each;
• The Total number of the solution's objects merged is 1170;
• The Total number of conflicting files is 140;
• The rate of successful automatic merge is about 88% (1170 – 140) / 1170 * 100 = 88%;
• Most conflicts are changes in the object's versions — trivial;
• None-trivial conflicts in about 20 files;
• Trivial find and replace was done on all merged objects (to fix RunFormOnRec -> RunPageOnRec, etc.);
• The result is a fully importable set of the most recent solution objects based on CTP5;
• The Number of compile errors after import is about 50;
• Most of these errors relate to changes in standard objects done from CTP3 to CTP5;
• The rate of faulting objects is around 4% (50 / 1170 * 100% = 4%);