Version Control

[Nibbles]

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.

[Alan Anderson]

Originally Posted by Nibbles

...I have never had a conflict in a binary file to resolve, but I can't imagine it would be painful to do...

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.

[whitetiger0990]

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

[Nibbles]

Originally Posted by Alan Anderson

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.

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...

[Greg McKaskle]

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