Source/version Control

[SuperS_5]

Hello, community.
I am a professional LabVIEW programmer, and this is my first year mentoring a team. I did a search of the forum about version control, I wanted to see what this community uses, but found very little. So after the lackluster search result, (probably due to my poor search skills) I was inspired to write this suggestion post.

Many programmers, (professional and non-professional) resist adapting to use version control, but I believe that it is essential. Although, one may manage without some kind of version control, it is very beneficial to use it. Even if a program is developed by a single programmer! When use correctly, version control is essentially a great backup system. It also allows for distributed work flow.

Version control works with all programming languages, but as I am a LabVIEW programmer, I will stick to LabVIEW. There are several solutions, 3 of which are quite common in the LabVIEW community; GIT, CVS, and SVN. I personally use SVN, with TortoiseSVN (TSVN) as the client. TSVN is a windows client that integrates with windows explorer instead of the development environment. This comes at the cost of tight integration. The project would have to be closed before updating the whole project. A major benefit is that any file type is supported. Documentation, VI's, LabVIEW project files, etc. There is a evaluation package available from JKI labs that allows TSVN operations on single/multiple files. (Whole projects get complicated) The evaluation uses a nag dialog instead of a time limit. In my experience, this combination of tools; VisualSVN, TSVN, JKI TSVN, has worked wonders for multi-developer environments and for recovering for computer disasters. I know that many developers use GIT, and CVS successfully, however, I find SVN very easy to set up. Other SVN clients for Mac, and various Linux distributions are also available, and mostly work together. (Programming technique would have to be more careful when using cross platform development, and I am not sure if the FIRST installers work cross-platforms.)

LabVIEW has some native Diff (difference) and Merge tools. They are usually located at <NI install folder>\Shared\ The sub-directory is the tool name. LVMerge, and LVDiff. I am not sure if they are installed with the FIRST installers, but will check when I get into work. The tools do not need to be installed, just copied onto the local hard disk. Most version control tools allow for external diff/merge tools to be mapped, and used instead of the client's native tools.

If there is enough interest, I will dig up the various tutorial
, and documents, and put together some 10min localhost setup tutorial. (Using a server, can be just as easy, but most school networks will cause it to be more difficult)

On a second note, I would also like to know how the community deals with multiple programmers, and backup methods. So please reply with your team's general solutions if possible.


Mike

[wilsonmw04]

Greetings Mike,
We have been a LV team since the cRio came out for FRC. We use LV in both FRC and FTC. I would LOVE to get any tutorials/info on what you have to offer.

Right now we have no official/systematic version control system. I have been prodding/harping/urging my two programmer to create some sort of version convention, but with little success.

[SuperS_5]

I will put something quick together probably tomorrow. Possibly get more detail if I get some help from the guys at work a little later in the week.

[Alan Anderson]

Originally Posted by SuperS_5

If there is enough interest, I will dig up the various tutorial
, and documents, and put together some 10min localhost setup tutorial.

Yes, please.

On a second note, I would also like to know how the community deals with multiple programmers, and backup methods. So please reply with your team's general solutions if possible.

When we have multiple programmers, they all use the same single programming computer. There has so far never been any way for conflicting changes to be made.

Backups are simplistic: when something significant is changed or an important goal is reached, the entire project folder gets copied and named with the time and date.

[Greg McKaskle]

The LV distribution for last year included SCC and other elements from the pro version. And thanks in advance for showing how you do SCC.

Oh, and I tend to use Perforce (not on a team).

Greg McKaskle

[DavidGitz]

We use LabView and Tortoise SVN for our Google Code Repository. We've been doing using this system for (almost) 3 years now and it's worked fairly well, although there needs to be a strict policy on making sure you are using the correct code (SVN Update before working on a file) since we have 3 computers that are running this software, sometimes all at the same time.

We have never used LVMerge or LVDiff.

[PSHRobotics]

I tried to set up subversion last year, but just didn't have the time necessary to read up and actually comprehend any instructions on it because it was towards the end of the season. I would really like to get version control going from the beginning of this year, so if you could put up a tutorial that would be incredible.

[kamocat]

I use Git, mainly because I don't like the central-server-dependency of SVN.
However, I'm not always stringent about committing often.
If I need something backed up, but don't want to create a new repository, I'll just zip it up where it is, so I can revert if I need to.

Last year I didn't teach my programmers to use revision control, because I didn't think they were there yet; they were still getting familiar with the language and with programming, and didn't understand why you would want to have regular backups.
This year I think I will. TortoiseGit should make it a lot easier. (A terminal is not an intuitive interface, even for me.)

[SuperS_5]

Hello again,
There seams to be some interest, so I will write a quick short tutorial for now.
<Warning: This post grew much longer then I expected. Please have patience while reading to the end >

For those that only backup by saving the whole project directory, this can work, but is error prone. It is very easy to mislabel a backup, and restore/delete the wrong data. Revision control removes that error, by controlling revision numbers, allowing browsing previous revisions. Tracking "whom did what" is incredibly easy. It remembers and controls what has and hasn't been changed, and what needs to be merged. Making a backup of the revision system, can be as simple as copying the "repository" directory, (only 1 backup is ever needed) or as complicated as mirroring. I continually convince my co-workers that are working on a project alone to use revision control. I can not tell you how many times it has saved me from trouble. When used in very complicated situations, (far beyond the capability of zipping the project directory, and the scope of this post) it is possible to create problems, although they can be easy to avoid using correct procedures.

I am not sure which version of LabVIEW will be shipped with the robot kit, but each version is full of new features. I hope they ship LabVIEW 2010 with the kit, because LabVIEW 2010 has a very valuable feature. It is able to separate compiled code from the source. This is a project settable option, and a VI settable option. This means if you start a new project, and choose this option, it is applied to all existing/new VI's in the project. In short, LabVIEW stores a lot of information in the VI file. 2 of those objects are the block diagram, (source code) and the compiled code. Every target requires recompilation. Many things can cause a code recompile, but it is very frustrating to cause a lot of conflicts when the code of those VI's where not actually modified. Setting this special option, completely eliminates this kind of conflict.

A good resource for multi-developer FRC projects is the FRCMastery site. There are a lot of procedural programming that really assists in preventing collisions when more then 1 programmer is working on the project at the same time. I highly recommend watching this video:

http://frcmastery.com/try-me/one-project-multiple-programmers/

Before I start, each team will have to evaluate their needs, and decide on the possible options. The options are:

• Localhost server (simplest solution)
• LAN server
• WAN server (Most complete, but expensive solution)

The localhost server option, can be free, and easy. It will not be accessible from other computers. It is however, a great backup solution.
The LAN server, is accessible via your local network. If the programmers will be physically near each other all of the time while developing, then this is a good solution. Somewhere between the LAN and WAN options, is the use of VPN software. This is a "virtual" LAN, and can be very complicated or simple. I personally use a program called Hamachi. It is near zero configuration. In any case, most school networks will probably try to block all VPN software.
The WAN solution will probably cost some amount of money. Most include wiki pages, bug tracking, and user control. Although some packages can be found for under $10/month, they are probably overkill, unless a team webpage/wiki are also required. A simple search will yield hundreds of results. If this option is chosen, I recommend it be setup well before the beginning of the kick-off because a lot of effort can be put into perfecting/customizing the system. All of the options can use the same client and operating procedures below. The server setup for WAN option, will be detailed on the providers website.

Server setup:
For the localhost/LAN options only. This tutorial will only outline how to setup SVN on windows. I am not as familiar with the other systems to write a tutorial off the top of my head. Administrator privileges will be required to install on most windows systems.
I recommend VisualSVN Server. It is very simple to setup and free.
1) Download at:

http://www.visualsvn.com/server/

VisualSVN is a SVN client that integrates into Visual studio. It is probably very useful for C programming, but, not very useful for LabVIEW. They do not offer much support for their free server. It is actually a nice installer and configuration for the open source SVN and Apache servers. It should just install without much trouble.
2) After accepting the license agreement, choose "VisualSVN Server and Management Console."
3) Choose install location, and repository location. The repository location may get fairly large, so choose a location with ample file space. I would recommend a minimum of 10x of the project size for last year. I guess in the neighborhood of 1GB, without documentation. The file size can be reduced, but must be done manually, and reduces the number of actual revisions that are available. A very large professional project that I work on consumes less then 50GB with thousands of revisions maintained. Revision systems are generally very efficient at data storage. Server port should default to 443, using a secure connection (https://) and Subversion authentication.
4) Allow the installer to complete. (We are almost done already)
5) Open the VisualSVN Server Manager. This is where users can be specified, along with passwords. For multiple developer, I suggest that each developer use a separate user name/password. This will be useful later when reading the commit logs for a specific file.
6) Add repository. Name it whatever you wish, but remember this name. (This name is used to access the repository, so choose something easy to type like, "FRC2011")
7) One can browse the source at https://localhost:443/svn (Remote computers should replace localhost with the computer's network name. At this point there won't be any files however.
8) Windows Firewall may prompt to unblock the server. Other firewalls/institution security parameters may require modification. These are outside the scope of this post. The localhost will probably always work. Network connections may be more challenging. Using the robot wireless Access Point will work, but connecting each computer to the router is also beyond the scope of this post. Again if there is interest, and more importantly time, I may write more on those topics also.

Client:
I recommend TortoiseSVN. (TSVN) There are other options, but I personally use this client. I am currently still researching alternatives, however, I have not found anything that works better for my use scenario.
1) Download at:

http://tortoisesvn.tigris.org/

2) Install, following all default parameters. Allow the computer to restart when the installer completes.
3) After reboot, navigate to a folder where you wish to store your code. Right click on the folder, and click "SVN Checkout..." In the "URL of repository" field, type in "https://localhost:443/svn/FRC2011" localhost again is replaced by the computer name if using a network and FRC2011 would be changed to the repository name chosen earlier in the server setup, step 6. Ensure that the "checkout directory" field is still valid. Sometimes the whole URL is inserted, which is not required. The recommended checkout directory is the folder that you right clicked on plus a descriptive folder name. (IE. FRC2011) Leaving all other options on default, Click OK.
4) TSVN will likely prompt to accept the security certificate. This error occurs when installing using this method. The certificate was created by the installer, but is not verifiable against a third party. Third parties charge a lot of money for this service, and is generally not required for this use scenario. "Accept permanently" will not prompt this dialog anymore. This is the recommended choice.
5) TSVN will prompt for an user name and password. Input the name/password chosen in the server setup, step 5. Each user again using a different log-in credentials.
6) The folder is now ready for files, and a project. Add a project, and make your first commit. (Everything in TSVN is accessed via right clicking on the appropriate file/folder in the windows explorer) Important note: Always add a reasonable comment when committing anything. Useless comments will only harm you later! Other users may now repeat, and will receive the new project.

Some important procedures:
1) Communicate! None of this will work if multiple developers do not communicate. This is critical!
2) Commit OFTEN! This is very important to avoid conflicts and data loss. Only files that actually have changed will be committed, so file size should not be an issue. This also means that saving before committing is a must. Closing the project before updating is also required without using other tools. (Other tools are available, but are beyond the scope of this post. I may elaborate in a future post)
3) If all of the techniques in the FRCMastery video are followed, collisions will be low, and generally easy to resolve. If LabVIEW 2010 is shipped available, use the "Separate compiled code" option. This will save a lot of headache. This one feature was my most desired feature in LV2010, and I don't know how I survived without it.
4) Make winning robot code. Good luck everyone!
5) Communicate! Sorry but had to add that again, this is so very critical.

Edit: There is a program that I also recommend called CommitMonitor. It is made by the same guy that makes TSVN. It is not required, but if SVN is used remotely, this tool is great. When setup (Using the same URL field above) it will alert you when someone commits something to the server. It allows for better communication and it can be difficult to directly speak to other developers.

I believe this is the end, but it has taken more time then I had expected, so there maybe something missing. After a very long day, I am going to catch the lunar eclipse. This means I have not proof read very well, besides I am a programmer, not an English major. I, therefore, request that you excuse any mistakes that I may have made.

Mike

[vhcook]

Thank you for this. Last year I had our student programmer use the zip/flash drive method of version control, which was adequate but not good. This year, we have several student programmers, and it's time to move up to a more professional technique.

[PSHRobotics]

Its a fantastic guide, thank you! The only thing that could be useful to add is that there are some services that provide free SVN support for WAN (at least I think they would be WAN) like Google code's project hosting (http://code.google.com/hosting/) and SourceForge (http://sourceforge.net/). The only problem I would see with solutions like these is the requirement of your code to be open source, but for most teams, I don't see this being too big of an issue.
I actually spent a decent portion of last night, time that should have been spend studying for finals but I decided that robotics is more important, trying to setup some of this on my own. I decided to go with Google's code repository, like David. It is pretty simple to setup as long as you find the the information to connect (like the password).
I went with Google instead of a localhost solution because we have three computers that we use for programing and with my school's network running a LAN server would just be a headache.
After messing with SVN for a little bit, I am now looking into setting up batch scripts to automatically update the code on each of the laptops at startup to avoid any confusion.

[SuperS_5]

I had thought about adding the free solutions that I found like the Google Code Repository and SourceForge, but did not think most teams would want it. I did not think that teams would want to release their entire robot code before actually competing. Of course, that is decision that each team would need to make.

In the 2 free providers above, you can control who edits the code and wiki pages, but cannot control who downloads it. Both providers are feature rich, and may be exactly what your team requires. I setup a test project on SourceForge, and it is similar to creating a new email account. They provide extensive help on setup, and configuration.

[SuperS_5]

I decided to restart my research into revision control because the early poll results. Of course the forum software is now finding revision control threads that I could not find earlier. Some of the interesting threads are:

http://www.chiefdelphi.com/forums/showthread.php?t=79535
http://www.chiefdelphi.com/forums/showthread.php?t=79446
http://www.chiefdelphi.com/forums/showthread.php?t=70297
http://www.chiefdelphi.com/forums/showthread.php?t=22974

Wikipedia has a short list of revision control software:

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

It shows the reason why there may be some confusion about which system is best. There are 2 categories of revision systems; distributed, and client-server. Although SVN is a client-server system, it is starting to blur the line. For networks that are overly restrictive, such as some school boards, a distributed system may be more useful. Unfortunately most distributed systems do not handle binary very well (VI's) when using some of the convenient communication methods like e-mail. I will be doing a more extensive research, and will identify which works better for LabVIEW and FRC together.
Stay tuned.

[kamocat]

What do you suggest for a bug tracker?
I know Trac is popular and integrates well with SVN.

Any ideas for Git? (I know GitHub has one integrated into their site, which is pretty cool, but that requires internet access)

[SuperS_5]

On a personal level, I love SVN/Apache/Trac solution. I use it everyday for work, and it is very customizable and works on almost any hardware. I have used it on "off-lease" and Atom computers. I am still investigating other soultions. What I have found so far is Google Code Repositories, and SourceForge have really integrated solutions with other revision control systems.
This is an interesting page:
http://en.wikipedia.org/wiki/Compari...g_facilit ies