0

Good Morning,

I am working on legacy code. This legacy code consists of multiple projects (language C with NI LabWindows CVI) and was never manged in a source control System but only in on folders. Over time it got a little messy and copies of this folder were created and changes were made to all folders depending the project that was built. The result is, that there are 5 folders each containing different codes bases for what once was the same code. Also many files were modified in all folders because they are used in several projects. Each project was only build from 1 of the 5 folder (so project A was only build in folder 1, project b in Folder 4 etc.). It is not only raw code, but also user interface files.

I hope that was clear so far.

My task is to merge all the code into one one codes base (as it started of originally). And I would like to get some suggestions.

Here is the plan: 1. create baseline version of one folder that is supposedly that one with the most changes. 2. create GIT repository to store the code and all changes 3. go through all folders and merge files into baseline version using file diff software. (Folder 1 is baseline, merge folder 2 to baseline, merge folder 3 to baseline etc.)

Do you have any comments on this plan? What is good? Bad? Are there tools I can use?

TriceratopsMagician
  • 13
  • 8
  • Make no assumptions on the veracity of content in any of the previous folders. Just because one .c file has more changes in it than the corresponding .c in another folder does not mean it was implemented better than the other. Start off with a list of user's needs, or, if they are available, the original specifications the software was written to. Then start with a clean slate, especially with the UIR files. (dump the old ones and create your own. CVI is notorious for UIR compatibility between versions. If you find the old .c/.h were written well, pull snippets from them, but start clean – ryyker Feb 22 '16 at 20:46
  • You are right about the assumptions. There are no original specifications because this software was developed on the fly and modified extensively with any requirement documentation or change documentation. Sometimes, when I get lucky the code is documented or contains a date/time stamp. Sometime when I am not so lucky these data/time stamps are completely outdated. Basically what you are saying is to re-do the whole thing? (or most of it) It feels like that would cause real trouble because all the unwritten requirements that developed over the years are hard to extract from the code. – TriceratopsMagician Apr 01 '16 at 21:07
  • If you have to re-do it, be firm about starting off with a set of derived requirements before starting the implementation on the new version. To some extent, the new requirements can be derived from the reverse engineering you will do in evaluating the original code and distilling what exactly was it created to do. Also, check with any other stakeholders (users of) the software to see what feature deficiencies exist, and add those to the requirements. Argue back it features do not contribute to the purpose of the software, but include them in the design if they do. – ryyker Apr 02 '16 at 20:31
  • I will. Actually even though I probably won't need to re-do much I will start deriving requirements. Almost all knowledge about 'how' and 'why' of this system are cultural knowledge and only share verbally. – TriceratopsMagician Apr 04 '16 at 15:55

2 Answers2

2

This seems like as good of a plan as any. You have a mess on your hands either way.

If there are many changes to the user interface panels, that could be a headache. The UIR files are binaries, which will make git merges and diffs useless.

Go into each project and under Options->Preferences select the box to save .UIR files as .TUI files and save the project. This will give you a text file output describing the user interface and allow you to use diff tools properly.

EDIT

When the User Interface is active, you can directly select Options->Save in Text Format to do this as a one-off.

Good Luck!

jkuz
  • 131
  • 1
  • 5
0

It might also be worthwhile to use the UI to Code converter under CVI's Tools menu to convert all your UIRs to code. This should make them more compatible with text-based source control (like the save in text format approach), but may also ease the process of merging UIs.

rak0ribz
  • 1
  • 1