Anyone of you tried Mercurial or Git?

[LuI]

I had a lot of discussion here in our devellopment teams about using SVN. Really good and free. But the problem of verioned linked libraries is not only a LabVIEW-related one, it exists in allmost all groups here.

We do believe that a distributed version control system like mercurial could help a lot here. Joel Spolsy gave a good tutorial at http://hginit.com/top/ that explains the problem and how mercurial solves it.

Has anyone of you considered using a distributed version control system or even mercurial. Maybe even with LabVIEW. Any experiences?

Greetings from Germany!

--

UF

[CharlesB64]

I don't really understand the problem of versoned linked libraries and how it is solved by DVCS?

However, I'm using git with a large LabVIEW project and perfectly happy. I'm the only dev on the project, but it could easily scale to more devs.

I have set up difftool to call the LabVIEW diff program, and the only thing I might miss is being able to merge (I know I could call LVMerge in git but I'm lazy to configure it).

Also, setting LabVIEW to "source-control environment" is mandatory (check here), or you'll get a lot of changed files in your commits

Also check this project for configuring Git with LabVIEW.

[LuI]

Charles B64,

thx for answering.

It is allmost impossible to keep links to versions of libraries. You can automatically connect to library code using the externals property, but when you revert to an older version the libraries are not reverted. And having those libs as sub-folders of the project using hardlinks does help neither. this becomes problematic when one has several devellopers and/or several projects. Have run into trouble with SVN here 😞

DVCS do not keep versions, but changesets, which is supposed to help. But I have no experience with this yet.

[Fire]

Subversion versus Git

We at GSI are providing a common Subversion repository for LabVIEW activities during the last few years and we were quite happy with it. Branching is rarely used.

Our repository contains many projects and libraries of many groups. The repository contains an entry point for each LabVIEW version (7.1-2011).

Subversion is use d here for several purposes:

1. source code control such as maintenance of common libraries and projects
2. Source and binary distribution
3. Quality management. Everyone can read the repository, but commit permissions for specific files and folders are granted to responsible developers only. So, it is not simple for contributors to submit changes, e.g. bug fixes, to the original developer or maintainer.

Some people are using the subversion repository as backup system which is not desired but difficult to avoid. So, the subversion repository does not always contain working versions. The repository is blown up.

Git seems to be a solution for many of these problems. But, as we learned from the previous, we would like to avoid one common project for all LabVIEW activities at GSI. So, the question is: How to disentangle projects files and common library files?

One idea is to include common libraries as subprojects within an project. That seems feasible if not two libraries A & B include the same third library C as subproject. The third library C becomes duplicated, which causes conflicts in the LabVIEW project. The same library or VI etc. in different locations is not allowed. The solution for that problem could be the usage of packed project libraries, lvlibp. Now you need to make sure those libraries A & B are build with the same version of library C!

Maybe there is a more difficult problem with lvlibp: Do the libraries A & B statically compile library C or do they link dynamically against library C? I did not found the time to test it. Did anybody else? Further more I had got a lot of not resolvable conflicts when replacing such libraries A, B and C with their lvlibp.

Summary: For small projects like instrument driver libraries not depending on other common libraries I can see no disadvantage for Git compared to subversion but a lot of advantages to deal with smaller independent projects. The difficulties start when using nested LabVIEW subprojects of nested packed project libraries. So, in our environment I am not yet really sure to switch from Subversion to Git.

Regards Holger

[barkeram]

I have been using TortoiseHg (Mercurial) on Windows for about a year and a half, on both LabVIEW and non-LabVIEW projects.  It works great, especially when you work on environments on two seperate networks.  With TortoiseHg, you can easily "export" your repository to an external hard drive and transfer all of your changes (and history) between disconnected networks.

Cheers,

Alan