how to organize it? what's your opinion?

Question

4.00/5 (1 vote)

See more:

Hello all,

I’m writing this to ask you about programming methods / version control methods.

First of all a small introduction:
I’m developing software for machines (see my web site if you are curious) this software development has two big sides:

a) HMI (visual C++ applications)
b) Control software (PLC like programs that control the inputs, outputs, movements… of the machine).

In the PLC applications (b) I’m developing using an OOP environment that allows me to do really cool things. In that environment is where I have the question.

Note that typically after finishing with a machine the code remains unchanged.

Let's go to the question itself:
In my case I program for example a class to control the movement of a drive, let’s say I can make as many instances of that class as I need (number of instances == number of drives).

Nowadays I have a folder where I’ve stored all the classes and I copy those classes to each machine project.

This gives me the problem that each time I update a class, I have different versions of that class in different projects. I will have to update it into as many projects it was working (only if it is needed).

This gives me the advantage that when I’ve finished the machine I have a complete copy of the final state of the machine and therefore I’m sure that I have the code that was installed on the machine.

In the other hand imagine that the class that controls the drive XXX has to be changed due to a change in the specs from the XXX drive manufacturer, then I won’t be interested in applying automatically those changes into the old machines (with the old XXX drive model).

What probably would be interesting is to have only a folder with the classes there, making different versions of those classes when different equipment versions appear and link to those classes from the different applications without copying them.

The only thing that worries me is that an innocent change would affect old machines behaviors…

How do you cope with that?

I can see advantages in both sides…

PS: till today the software that I’m using to program did not allowed me to develop using a centralized set of files so there has not been the need to ask, but now the new version is here and (even I’m not sure this is something allowed) probably it will and the doubt has appeared.

Thank you in advance for your comments.

Posted 9-May-12 9:28am

Joan M

Updated 9-May-12 20:42pm

v2

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Peter_in_2780 · Answer 1 · 2012-05-09T13:00:00

Hi Joan,
This sounds to me like a good candidate for a source control system. You maintain a "trunk" with the latest version, and each time you build for a particular machine/client, you fork off a branch for that build.
When you want to retrofit updates to older branches you simply extend the branch with the relevant changes.
I don't have any good references to hand, but I'm sure you can find some intelligent discussions about this use of source control.

One problem that is NOT solved by this approach is a change in your toolchain (eg compiler) where the same "old" source code produces a different result if you recompile later. But then, there aren't too many ways to handle this except for keeping a copy of the old toolchain, and hoping you can still find a system to run it on.

[disclaimer: This answer is uncaffeinated, so could be greatly improved. All welcome!]

Cheers,
Peter