Version control of distributed software

[BowenM]

Like the subject says, I'm working on a way to control versions. I will be writing several small applications that will be used throught the company by 20-30 people. If I do an update or bug fix, I want a way to make sure everyone is using the most recent version.

I started writing my own, but thought I'd check and see if someone already has a solution.

Edit: clarity

[crossrulz]

Software Control Software!  Something like Tortoise SVN works wonderfully for this.  You just commit your code updates and then make everybody do an update.  They also have the option of sticking with the old code just in case they don't like your update.

[BowenM]

We use SVN for version control, but the problem is - I'm not even sure who all will be installing the software so I can't easily make them update. More important, because the program will be used to analyze data for customers I can't give them the option to not update, it has got to be forced.

My initial plan was to basically write a "lunch" application. Running it will bring up a list of programs I've written (populated from a network share) that they can lunch. Versions will be imbedded in the file and if their version is wrong, or if they have never run the application, it will update by copying over the new executable / support files (basically the entire built application) before running.

But someone has to have run in to this problem before...

[LV_Pro]

Having your programs "phone home" to a database/list maintained by you to let the program determine if it is the latest/current version before it can run?

P

[BowenM]

---

@LV_Pro wrote:

Having your programs "phone home" to a database/list maintained by you to let the program determine if it is the latest/current version before it can run?

P

---

That was basically my plan, but it seems silly to reinvent the wheel if someone already has a solution to this. Almost every single commerical program you use on your PC has some method to update itself. This isn't exactly a new problem...

[dkfire]

One thing there is out is Wirebird's Deploy:

http://wirebirdlabs.com/deploy/

I have not used it, just looked at it.

[jyoung8711]

I use git to manage a lot of my LabVIEW projects, and like it a lot.  Though it can be a little nontrivial to deal with diff and merge actions (you have to get git to use the correct program to deal with this)

I've also just used a shared dropbox folder, and that can work out well, depending on what exactly you're trying to accomplish.

Regardless of how you decide to deal with version control, I recommend separating the compiled code from the VIs.  LabVIEW has a tendency to recompile large portions of code after only small changes... this can mean that version control will try to update a huge number of VIs after an update.  By separating the compiled code from the VIs, LabVIEW will store this in a different location on your computer, and only direct changes to files will cause the VIs to be recognized as changed.

[BowenM]

Wiebird's deploy looks interesting. I'll have to look at that a bit more.  Thanks.

[Sam_Sharp]

I've been using Deploy in my company for quite a while now for our software (it's all internal to the company) and we have some software that's installed on ~50 PCs and needs to be kept up to date. It's very easy to implement functionality in applications for checking for updates (from a network location, FTP server) and installing them automatically but it also does a whole lot more than that, it's infinitely customisable and offers a whole load of things that aren't possible in the NI Installers.