Quote:
Originally Posted by mluckham
Some of the replies here talk about version control systems - that's too advanced for us, I will just have individual programmers work on Labview VIs independently (eg: joystick input and scaling, motor speed control with encoders, pneumatic arm control with limit switch) and convert them to subVIs, then have one or two of the programmers bring these subVIs together in the main program.
|
I would argue that version control is good for your situation too. I use it for individual projects where I am the only guy working on things. That way, every time your code gets checked in, it gets backed up, and you can go back to that place in time if you run into a problem. I consider myself to be pretty good at programing, and I have still used revision control a couple of times now to figure out what I changed between right now and a couple of minutes ago that caused my code to stop working. It probably saved me a couple of hours. For me, it has gotten to the point where when I work on a piece of code and it isn't in a revision control system, I actually feel uneasy until I have put the code in a revision control system.
In your situation, I would view a revision control system as more of a "backup system" than something to do all the fancy merging and all that that revision control software also does. Your revision control system could even consist of a folder on the school's server that all your programmers can access that you zip everything up nightly, adding the date to the folder name, to back it up. That is all that most pieces of revision control software will do for you anyways when you are using binary file formats like labview (I'm assuming that labview uses a binary file format), since you can't merge binary files together unless you actually know how the binary format works and can teach the revision control software that.