preferred source control provider

[Lucy]

Hi,

In my new job, I haven't selected a version control package for Labview yet and there's also reviewing the need for general version control and IP protection across the business - is Dropbox enough?

Could I have your thoughts on the best source and version control software to get that gives best Labview integration.

Should I be aiming to spec something that as well as being the integrated Labview source control provider can be used for more general IP control or is it best kept separate. The Physics guys use GitHub individually and would like to be more integrated. It doesn't have to be free, but of course low cost is best.

I'm sure this question is covered in the general forums, but the ones that come up are all several years old,  so I'd appreciate your thoughts at this time - I trust you guys, confirmed by the NI weeks award!

Lucy

[swatts]

I personally like SVN with the tortoise client, it's simple, gives good integration with LabVIEW and for us it does a very nice job. The post-commit hooks are all pretty easy to understand and this is useful for informing your stakeholders. Also the command line is easy to use and comprehensive.

That said git and mercurial offer an additional layer of backup by being distributed. I thought that git was a bit more difficult to use but if your chaps are used to it I would perhaps swing that way. There seems to be a reluctance to use SVN after you've got used to git.

Mercurial has a good client in tortoisehg and offers distributed advantages. One day I'm guessing we will move towards this.

The other thing to get to grips with is the misconception that good SCC controls will do all your software management for you. So on top of any of these tools you need to train everyone up to use it in the same way. Make sure your projects are all set up in a common fashion etc etc.

Security/IP is a matter of company policy. If you are not being given guidance on this I would always opt for most secure and pay a bit (you're unlikely to be sacked for being too secure)

[Swinders]

A number of years ago we decided to use Perforce and it integrates very well with LabVIEW, files can be checked out or submitted from the LabVIEW project. There is also a desktop client that you can use to perform check outs and submit files and look at the check in history.

The Perforce sever runs on one of our physical(virtual) servers and each developer can connect up and perform the necessary actions on the depot. It is a commercial product so there is some cost but there is a low cost 20/20 license that allows you to have up to 20 users/workspaces for zero cost and support is still available.

Besides the LabVIEW vi's we also store project documentation, mainly word documents and these are handelled well.

We have a workflow that works well for us with LabVIEW and Perforce. I think the most important thing you should consider is whatever system you decide on it has to be used for it to be any use.

[MikeeB]

One thing to consider is how many people will be on an active project. We use SVN, however with more than one person on a project people are loath to check in anything until it works as it would break the build. Git would allow us to check in locally and maintain more check in points for each thing we do before pushing to the main repo. Other than that both are easy to work with, but lack direct integration with LabVIEW. We tried TSVN and found that it broke LabVIEW on occassion so just work with SVN through Windows Explorer  Mike

[Richard_Ha]

We're using Microsoft TFS (there a lot of .NET software delvelopment done on site).

It integrates really well with LabVIEW, but causes all sorts of problems when working remotely.

[James_McN]

Hi Lucy,

I now exclusively use Git with LabVIEW through using TortoiseGit.

Likes -

• Tortoise git does all I need through windows explorer.
• Well supported in additional tools.
• Well backed up. If I lose either my laptop or server (through failure, breaking repo through mucking about, acts of god) I don't lose anything.
• Can use SSH to talk to server. Means I have one password prompt at the start and don't have to enter credentials every time but can be hard to set up.
• Not dependent on server connection (because I can end up working on site alot with iffy internet connections this is good for me)

Cons -

• It is a little harder to get started with due to a more complicated workflow (Although TortoiseGit shields you from alot)
• Commit and sync with server are two different operations. This can help workflow but you must remember to do both!
• No tight integration with LabVIEW

Unknowns -

The multiple user scenario is interesting. It is better because they have their own repos so theres no waiting until so and so has finished this and check it in or having to wait until everything is just so to check in.

However it does mean if people don't regularly sync with the server you can get more of a mess with the amount of stuff that needs merging. This is a discipline/workflow issue combined with LabVIEWs difficult merging.

I've not used Git or SVN in this environment so can't say for sure if one is better, from the outside I think this is an issue with either though.

For general IP I tend to keep this seperate although it is a little case by case. Some things such as user guides might end up in source code control but things like design drawings I keep in google drive (similar to dropbox) unless they are tied to software versions in some way.

[yenknip]

I use SVN through TortoiseSVN, and I manage with multiple developers.

I feel any merge action with LabVIEW is still awkward, so I manage projects to avoid complex merging. Each developer has a defined part of a project to work on, so merge to trunk can be completed regularly and with little fuss.

This is my main issue with GIT, by design it is based around the idea of lots of branching and merging, so if multiple developers and repos get too out of sync then the Big Merge is, well, awful.

[danny_t]

Hi

We used Mercurial here, we have two developers in the UK and one in the US it works well for us. Git and SVN are also both good choices. It used to be you had to pay for any worthwhile tool, but the free open source tools are now real and valid major players in this area. The one thing I will say is that Dropbox is not in any way a source control tool.

The previous comment about process is very true, you could have the best source control tool and it is pointless unless you have a agreed working procedure on how to use.

There are two main lines of thought in source control today, centralized systems (SVN, Perforce, ClearCase) and distributed system (Mercurial, Git). I would suggest your starting point is to understand the differences between these two and choice which way you want to go before you actually look at which tool to use.

These links might help.

http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

http://http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/

http://stackoverflow.com/questions/111031/comparison-between-centralized-and-distributed-version-con...

Another area to understand is the concept of branching and if it is something you wish to use in your process and if so how you would use it.

A reasonable overview can be found here

http://betterexplained.com/articles/a-visual-guide-to-version-control/

Branching with LabVIEW can be a problem, I know there is a LabVIEW merge tool but I have never really found it to be something practical to use in a day to day way. We do this branches a great deal to keep our work packages separate but we always plan our work out to avoid two people working on the same LabVIEW Vi. Also we always use the seperate source and compile code option to stop unexpected merge issues.

If you look on LAVA or the NI forums you will find that SVN, Mercurial and increasingly Git is being used by LabVIEW programmers and there are a number of tools, both free and commercial, to help with LabVIEW integration. You may read that Git is a Linux supported tool with very poor Windows support but that has change over the last couple of years.

[danny_t]

Regarding the comments about branching and merging.

I HATE hate hate merging individual VI's in LabVIEW it might work for a file or maybe two but it is not the way to go. I will do everything to avoid it.

Merging with text files just works, mostly 🙂 , the tools are long established and source control schemes are well documented. But even with text files there comes a point where merges are painful.

But this does not in any way stop me using branches and merges, I fact without understand what branching gives you and how to do it, in my view, significantly reduces what you get out of using any source control tool. There are good cases to use branches even if you are a sole developer.

The key to good branching is understanding the concept and planning how you are going to use it. This comes back to the earlier comment about good processes that are explained to the developers and followed. Such a process is not fixed in stone, it can and will change over time to adapt to what your organization is doing. It may even be that different project require different branching strategies. This is all fine as long as it is agreed, explained and followed.

The concepts of good system design will also significantly help with branching and merging. Keeping components uncoupled and using library will help generate branching that are independent of each other and therefore reduce possible merge issues.

A golden rule of branching is to merge often and early, this is true with text languages and LabVIEW, it is the developer who refuses to merge changes out to their branch and keeps their branch open for a month or so who kill the project with a "killer merge"

[FabiolaDelaCueva]

Once you decide what tool to use, if you go for SVN, Mercurial or Git, here is a post we made with some videos on how to set up your LabVIEW environment to work with those tools:

http://delacor.com/every-developer-needs-a-time-machine/

Enjoy!

Fab