Version Control
 

Hello CD!

My team was planning on using Subversion for code storage and version control this year. Some of my teammates have also suggested using Git.
My questions are:

•Which version control systems are supported by Windriver? Do Eclipse plugins work?
•Does NI support a version control protocol in Labview? If so, which?
•Which version control system is your team using?

Thanks!
--Jordan

Re: Version Control
 

I can't speak to integration with windriver or labview, but we use Git. I love it. We used it last year.

http://code.google.com/p/msysgit/

It has a GUI that works on windows now. =)

I don't see the point in having it integrated with the environment, so I think your first two bullets are not applicable ;-). After I'm done and have closed labview I just double click the git shortcut for the repo I have on my desktop and I commit it. If I'm at home I can push it up to my server.

I very strongly recommend Git. I really love how it handles being completely decentralized.

Re: Version Control
 

git sounds cool.

Also, I completely understand where you are coming from. I usually just use a text editor (im on a mac, so TextMate) or emacs (on linux), and then use the command line versions of these systems.
We have many many newbies this year, and as long as we have a nice commercial IDE, why not use it?

---Jordan

Re: Version Control
 

Eclipse plug-ins do work. The version of eclipse in Workbench is 3.3.1 so you need to select plug-ins that are compatible with that version.

We've been using subclipse inside of the environment and it works quite well. Outside of Workbench we've had good luck with tortoisesvn. If you decide to build the C++ version of WPILib you need to install sliksvn to not have any build errors. We use the sliksvn command line tools to do version number updating in the library.

Pretty soon there will be a sourceforge server running with the C++ source code on it, and having something integrated will make your life easier if you plan on using the source code.

Re: Version Control
 

Git is the most amazing thing I think have ever used. What is more brilliant is Linus himself who designed the thing for the Linux kernel in just two weeks (and released the next version of the kernel a little more then a month after). It can be a bit tricky learning Git, it doesn't use many of the same names for common operations that other revision control systems do, and there are many habits you have to break and get into, mostly due to the amazing branching and merging it can do. Decentralized is a great feature for teams, you don't have to be connected to anything to make a commit, because you are your own branch, you just commit locally and push to a public repo when you can (though setting up a system can be hard to figure out, it isn't made exactly clear). Not to mention, fast fast fast like switching to apt-get after using emerge all your life (Gentoo users will get the joke), even transferring history over a network, it can often compress and store the entire history smaller then a single SVN checkout. Git can import and export SVN too, but that isn't as great, nonetheless it works (Linux versions at least). I can track a line of code as it moved through multiple files, I love that. For additional convincing, watch http://www.youtube.com/watch?v=4XpnKHJAok8 for an overview by Linus and http://www.youtube.com/watch?v=8dhZ9BXQgc4 for a more technical look into how it is used.

The really expensive versions of LabView natively support many different types of revision control systems (it ties into Microsoft Visual Studio somehow) to support graphical equivalents of diffs and conflict resolution, but it (I am pretty sure?) doesn't come with the kit. Git is pretty good with merges, though I am not sure how well it will handle VI's (they appear to be binary files, I have never had a conflict in a binary file to resolve, but I can't imagine it would be painful to do). Additionally, if I understand correctly, LabView can save to a new file for each change you make, and tag it with your name and a date and such, but that could get really big really fast.

Re: Version Control
 

I believe you are mistaken about the amount of effort it would take. Imagine trying to resolve differences between simple .hex files for the IFI control system.

Re: Version Control
 

Yeah, with LabVIEW merges are impossible, but I don't really see that being a deal breaker.. We can merge by hand if needed.

<3 git

Re: Version Control
 

VI's should be simpler then a compiled file (why would you version a compiled file anyways?) because you can inspect and edit it directly, but, yeah, it turns out it is quite a bit of effort. I tested it out, merging VI's I am having a hard time with, having the native diffing tools would really help (otherwise it would be a simple edit to the repo config file specifying the path of the tools). I am also unsure if the VI may be formatted differently when moved between computers or versions of LabView. It appeared simply opening up and closing a project changed it, but Git had no problem merging this (it should be that simple for SVN too, it has a single parent). Merging different changes it got caught up with, and I can imagine this happening all throughout the build season and having to repeatedly visually inspect both versions and manually merge them by hand. Best case it could be a 15 minute task each time, still bad news. It looks like there is no good versioning system for LabView projects available to teams...

Re: Version Control
 

LV VIs are indeed binary, and they shouldn't be merged by external tools. The LV PDS (Pro Dev Suite) includes connections to a few external SCC tools, and an internal diff utility. It does a graph comparison looking for nodes that are considered to be the most similar, and works outward along the edges of the graph until it can describe the differences.

In other words, this is sort of like comparing lines of a file and deciding which are most similar, etc. But it is also quite different, and unless an external tool knows about the LV graph, they can store, compress, and retrieve, but should not merge.

Greg McKaskle

Re: Version Control
 

We used SVN last year with good success. SmartSVN is our client program to download on mac or windows.

We uploaded VIs in SVN to keep track of the version. We found that just putting the VIs on without conflict checks was sufficient for most of our testing. Comparing two VIs for conflicts would be nice but you can do quite a bit with good comments on each revision you commit.

Re: Version Control
 

I'm new to FRC and was wondering how teams handle multiple developers. My team was thinking of using svn since there is a plugs-in to workbench/eclipse.

Where do teams actually store their sw? svn/git/whatever provide access to a repository somewhere. I was thinking of using code.google.com which provides free hosting for projects. Another idea for something similar would be to use sourceforge. Our team has internet access in the school so we can check in/out updates during the build season. Some possible advantages of using something like this are:
- offsite backup in case computers/disks die, are stolen, lost, etc..
- students/mentors can access code from home or school
- other teams can see/find the sw so it makes it easier to ask for help or give help
- gives students experience with real life project tools/process

Any thoughts about this or suggestions for other ways to store s/w in some kind of repository? Thanks.

Re: Version Control
 

We are probably going to store our code on a friend's server this year, but in the past we have just set up a svn server on one of the team laptops and used that. Since the laptop was always with all the programmers, it worked out fine. code.google.com looks like a great idea though, and the only thing that prevented us from using it in the past was the license agreement on Kevin's code. Which shouldn't be an issue any more.

Re: Version Control
 

I can create SVN repositories on our server for anyone that's interested - shoot me a PM.