Source/Version Control

[Ben Klebe]

Hi guys,

I'm the programming lead for team 5347, The Gryphons.

Our season is over, we are a rookie team and did not win. I am currently working on preparations for next year, and this includes organization of our codebase so that we can collaborate effectively and keep everything neat.

Our current source control system is kludged together through email, and it is not a system I'm eager to keep. In light of this, I've been examining other options for source control.

We currently use LabVIEW, though one of our mentors is trying to convince us to switch to Java, because of the support that will be provided by the wealth of Java programmers at competitions and supposedly on Chief Delphi as well. I'm not entirely convinced yet, because even after 2-3 months of struggling through LabVIEW stupidly not reading the quick start docs I should have, I'm beginning to recognize the beauty of graphical dataflow programming much due to my discovery of the clean-up diagram tool.

I've spent a few hours looking through a list of source control systems that integrate directly with LabVIEW. I've considered trying to get Perforce on board as a sponsor for a license or too, but was wondering if anyone has had success trying to get LabVIEW to work with GitHub or any other free source control providers.

[joeyoravec]

Originally Posted by Ben Klebe

We currently use LabVIEW, though one of our mentors is trying to convince us to switch to Java, because of the support that will be provided by the wealth of Java programmers at competitions and supposedly on Chief Delphi as well.

There might be reasons to use Java. Do all the students on your team have Java experience? Does your school have a Java programming class that you are planning to piggy-back off of? Are your software mentors Java experts? Are other local teams only able to help you if you're using Java?

LabVIEW is pretty easy for students who have no prior programming experience. This allows us to focus on robot functionality and design, instead of how to work the programming language.

Originally Posted by Ben Klebe

I've spent a few hours looking through a list of source control systems that integrate directly with LabVIEW. I've considered trying to get Perforce on board as a sponsor for a license or too, but was wondering if anyone has had success trying to get LabVIEW to work with GitHub or any other free source control providers.

LabVIEW VIs are opaque binary data; almost any tool will manage them in the same way. Consider the easiest solution that meets your requirements.

How many programmers are on your team? How often are people working on the code simultaneously? How many times did you branch, merge, or compare older versions of the code during this build season?

Our team uses a shared folder on dropbox and creates a new copy at every meeting. It's simple, but it works fine for what we do.

[Greg McKaskle]

There are two approaches.

You can use one of the tools that plug into LV. This allows for edits to automatically prompts for checkout, for checkins from a right-click, etc. But there are only a few supported at this level.

Or you can use a SCC tools that LV plugs into. In this scenario, you go to the tool to do the things I mentioned above, and you use the LVCompare program to compare two files.

If you google, I believe you'll find instructions for Git and other tools.

Greg McKaskle

[wt200999]

Originally Posted by Ben Klebe

I've spent a few hours looking through a list of source control systems that integrate directly with LabVIEW. I've considered trying to get Perforce on board as a sponsor for a license or too, but was wondering if anyone has had success trying to get LabVIEW to work with GitHub or any other free source control providers.

You can use Perforce for free, the only limitation is that you cannot have more than 20 users. Just remember though, that with a system like Perforce you need to have a dedicated server set up. With something like Google Code or Github you can store the repository on their servers.

Our team has been happy with Perforce, and we have it set up the second way that Greg proposed. We use the P4V GUI to manage our files with no plugins to LabVIEW itself, and we plug LVCompare and LVMerge to that tool. The compare and merge tools are a bit tedious to use however, so we make good use of the lock tool in Perforce, and we make sure students on our team don't manually set files to non-read only. One huge feature we missed this year is the P4Sandbox tool, which allows local & private branching. We were lucky that our regional had good WiFi in the pits, but I know a lot of events don't have this which makes it hard to use perforce at competition (at least without using P4Sandbox).

Whichever tool you do decide to use, make sure you spend a little time with anyone who will be contributing to the repository to train them on proper usage.

[tcjinaz]

Originally Posted by wt200999

You can use Perforce for free, the only limitation is that you cannot have more than 20 users. Just remember though, that with a system like Perforce you need to have a dedicated server set up. With something like Google Code or Github you can store the repository on their servers.

Our team has been happy with Perforce, and we have it set up the second way that Greg proposed. We use the P4V GUI to manage our files with no plugins to LabVIEW itself, and we plug LVCompare and LVMerge to that tool. The compare and merge tools are a bit tedious to use however, so we make good use of the lock tool in Perforce, and we make sure students on our team don't manually set files to non-read only. One huge feature we missed this year is the P4Sandbox tool, which allows local & private branching. We were lucky that our regional had good WiFi in the pits, but I know a lot of events don't have this which makes it hard to use perforce at competition (at least without using P4Sandbox).

Whichever tool you do decide to use, make sure you spend a little time with anyone who will be contributing to the repository to train them on proper usage.

You're pushing me to GIT. We never have internet access at the event in AZ, except what you can set up via cell phones.

[randantor]

This year 624 is using Git with LabViewGitEnv (https://github.com/joerg/LabViewGitEnv).

It went okay, but once we got a significant number of VIs in the project merging became such a long and protracted experience that we stopped doing it, keeping everything on a single branch, because for every single changed VI (and they change for some reason whenever you open them) it has to start up LVMerge over again, which takes quite a while to load, and then the project fills up with "file conflicts" that you have to manually accept for every single changed VI. That negated one of the most significant features of Git, which is that you're (usually) able to maintain parallel branches with easy merging between them, allowing your team to collaborate and multitask.

We found that it was helpful to use auto-populating folders for VIs in the LabVIEW project, and to review changes before committing them to avoid including a VI that wasn't really modified. We also removed the .aliases and .lvlps files from the repository, because merging would corrupt them and they seem to be regenerated by LabVIEW anyways. Git would also corrupt our lvproj file sometimes in merges, which we fixed by hand when it occurred (It's an XML file).

All in all, I don't know if it was worth it. The benefits of collaboration and multiple branches were nice early in the build season as we prototyped different elements of the code, but once we started integrating different code elements together and editing the same VIs merging became very tedious. However, the ability to go back to your code at any point in time in the past is very helpful.

If you use Git (and this may apply to other version control systems as well), I would recommend to really try to avoid working on the same VI in different branches, because merging really isn't fun.

[tcjinaz]

Interesting observations. Thank you, randantor. I needed to hear about LabViewGitEnv.

We have been cursed(blessed?) in our 4 year history with never more than two working on the code. In that context, I think accept most of git's problems, but corrupting an XML file is not encouraging. This year we got to where we turned on LabView's version comment facility. Next year we'll get to real CM.

[Greg McKaskle]

If you are going to use SCC, you may want to change the VI to store source and the binary executable code separately. The checkbox is in the VI Properties dialog on the first page. There are probably other ways to turn it on for the entire project.

Greg McKaskle

[Ben Klebe]

Originally Posted by joeyoravec

There might be reasons to use Java. Do all the students on your team have Java experience? Does your school have a Java programming class that you are planning to piggy-back off of? Are your software mentors Java experts? Are other local teams only able to help you if you're using Java?

LabVIEW is pretty easy for students who have no prior programming experience. This allows us to focus on robot functionality and design, instead of how to work the programming language.


LabVIEW VIs are opaque binary data; almost any tool will manage them in the same way. Consider the easiest solution that meets your requirements.

How many programmers are on your team? How often are people working on the code simultaneously? How many times did you branch, merge, or compare older versions of the code during this build season?

Our team uses a shared folder on dropbox and creates a new copy at every meeting. It's simple, but it works fine for what we do.

We have a very small team, ~15 members. It could be less next year. As it stands, the programming team consists of me and one other guy. As you said, the main allure of Java is support, but I'm not sure I'm ready to take it on. I've bounced between several languages, I was weaned on Logo with a Cricket then graduated to NXT-G during my FLL years. LabVIEW brings back memories of NXT-G for me, (because NXT-G was built by NI and is very similar to LabVIEW) that's part of the reason why I'm starting to get comfortable with it. Our school doesn't really have a formal programming class, so we unfortunately can't use that for support, though my dad has almost 20 years (since inception) of experience with Java and I believe our mentor has some too.

What draws me to LabVIEW specifically is the ease of data collection, graphical interface, and the idea that it is developed by the same people that make the cRIO and now the roboRIO. I suppose that's mostly symbolic, as the device obviously doesn't care what language generated the binaries it runs.

I have wanted to use Google Code/Drive and Dropbox and specifically asked to, but our last head programmer was messy with his source control and it has convinced our mentor and coach that a more dedicated solution is required.

Originally Posted by wt200999

You can use Perforce for free, the only limitation is that you cannot have more than 20 users. Just remember though, that with a system like Perforce you need to have a dedicated server set up. With something like Google Code or Github you can store the repository on their servers.

Our team has been happy with Perforce, and we have it set up the second way that Greg proposed. We use the P4V GUI to manage our files with no plugins to LabVIEW itself, and we plug LVCompare and LVMerge to that tool. The compare and merge tools are a bit tedious to use however, so we make good use of the lock tool in Perforce, and we make sure students on our team don't manually set files to non-read only. One huge feature we missed this year is the P4Sandbox tool, which allows local & private branching. We were lucky that our regional had good WiFi in the pits, but I know a lot of events don't have this which makes it hard to use perforce at competition (at least without using P4Sandbox).

Whichever tool you do decide to use, make sure you spend a little time with anyone who will be contributing to the repository to train them on proper usage.

The server is the hard part of that. As a team with precious little funding to spare, I'm not sure we could set up a server for it. I have a few old PCs lying around, but I don't see the point in trying to convert them to servers before I know whether or not it will be time well spent.

As for GitHub, we considered it, but for LabVIEW, the process for integration seems finicky. Does anyone have any specific tutorials on how to do it? This is the only one I've found so far:

https://www.youtube.com/watch?v=2dEI6tEMTmQ

The only other concern with using GitHub is the privacy of our code, which may be a non-issue. I haven't decided yet. Does every team open their source during build season?

[Invictus3593]

Originally Posted by Ben Klebe

The only other concern with using GitHub is the privacy of our code, which may be a non-issue. I haven't decided yet. Does every team open their source during build season?

I'm not sure privacy would be a real issue. Your team's programmers and their mentor should be the only ones who know where the code is and as long as they don't go post the link somewhere online, I don't think it would be easy for the public to find your code on GitHub.

[randantor]

The only other concern with using GitHub is the privacy of our code, which may be a non-issue. I haven't decided yet. Does every team open their source during build season?

I may be wrong, but I remember hearing somewhere that FRC teams can get free GitHub organization accounts, which allow you to have private repositories that are only accessible to team members.

We've just hosted our git repository on a cheap VPS that we already rent to run the team website, though.

[Ben Klebe]

Originally Posted by Invictus3593

I'm not sure privacy would be a real issue. Your team's programmers and their mentor should be the only ones who know where the code is and as long as they don't go post the link somewhere online, I don't think it would be easy for the public to find your code on GitHub.

Exactly. The question is whether we want security and privacy or scantily guaranteed pseudo-privacy.

Given how I'm not even sure how to set up a LabVIEW repository on GitHub in the first place, as well as the fact that you can get Perforce for free with ~20 users, I'm almost convinced I should just get into the morass of converting my desktop into an Apache server with Ubuntu Server and Perforce. I could use it to host our website too.

Anyone else here have any advice for LabVIEW vs Java? The benefits I see of LabVIEW are ease of learning, ease of debugging, and data collection. The only benefit I can really see of Java would be support, but people here are probably more experienced with it than I am.

[Dkt01]

Originally Posted by randantor

I may be wrong, but I remember hearing somewhere that FRC teams can get free GitHub organization accounts, which allow you to have private repositories that are only accessible to team members.

You're right. Github has educational organization accounts with 20 free private repositories. See http://education.github.com for more info. FYI, give them about 1-2 weeks to process your request. Students (high school and college) can get 5 private repos as well. Look on the same site.

[The Doctor]

Originally Posted by Ben Klebe

Given how I'm not even sure how to set up a LabVIEW repository on GitHub in the first place.

Github can host any files, even executables. LabView should be no problem.

[Landonh12]

This year 364 used a BitBucket mercurial repository with TortoiseHg Workbench. You can commit, push, pull, and merge, but you obviously can't see changes without opening the code. Commit messages are really important since you can't see changes on the fly.

TortoiseHg: http://tortoisehg.bitbucket.org/
BitBucket: https://bitbucket.org/

Screenshot of TortoiseHg from our repository: http://i.imgur.com/QhCvkhm.png/