53 replies to this topic

[Jim Kring]

Has anyone used Mercurial for source code control in LabVIEW? It looks like it might be the next step in the evolution: CVS ==> SVN ==> something that can merge/branch worth a damn.

Cheers,

[Ton Plomp]

No, I have not. I was tempted to start testing git during my holiday, but the sun was better to sit in than work in.

On Stackoverlow is an extensive discussion on differences between the two distributed SCC systems.
This discussion points to this blog-post by Patrick Thomson, reading that puts Git in the Linux corner and Mercurial in the more polished OS's (no flameware intended).
I think you will like this comment:

Despite that glaring flaw, the rest of hg is excellent. It functions almost identically to Subversion in the commands that it shares, and the new concepts – branching, merging, etc. – are easily learned and intuitive. Whereas I’m still learning how to do relatively basic things in git, I learned pretty much all of hg’s functionality in about a day. If you’re familiar with Subversion, transitioning to Mercurial should be a piece of cake – the functions you’re familiar with will be there, and the new functions are easy-to-learn and well-documented.

All in all mercurial looks better if you want to get started fast.

However merging is still a pain LabVIEW.
Related question has anyone ever tried to integrate it's own version control provider? I looked at it to bring a native support for SVN (without PushOK), but the API (or something that resembleds an API) provided by NI is not very well documented.

Ton

[Gary Rubin]

We've just started using Mercurial on our Matlab code. I think we'll probably try bringing in LabVIEW code in the next few weeks.

[Jim Kring]

All in all mercurial looks better if you want to get started fast.

However merging is still a pain LabVIEW.
Related question has anyone ever tried to integrate it's own version control provider? I looked at it to bring a native support for SVN (without PushOK), but the API (or something that resembleds an API) provided by NI is not very well documented.

Ya, I've read those links too. I'll be curious to hear what people think after using LabVIEW with Mercurial.

Regarding the SCC API, the other problem with it, IMO, is that the API assumes a locking (check out / check in) model, which doesn't really fit well with concurrent access (commit and merge) models.

We've just started using Mercurial on our Matlab code. I think we'll probably try bringing in LabVIEW code in the next few weeks.

Cool! I look forward to hearing your results.

I'm going to try to find some opportunities to play around with it, too.

Thanks,

[harbenger]

Jim,

I am curious what you mean by something that can merge/branch worth a damn. Is this a LabVIEW problem or a general SCC issue? It seems to me that the choice to move beyond SVN is largely motivated by the desire for distributed version control. I would be curious to know how much paradigm shifting has occurred in the new flavors of version control. In other words, do the new version control systems provide any better support for the basic versioning actions (checkout, committ, branch, merge, etc)? Git seems to be one of the few that claims to have started from scratch (and not from CVS/SVN) which may address this for you.

I too have been looking for a new version control strategy. I've been looking at Bazaar which appears (at first glance) to be very similar to Mercurial: Python based, distributed version control and can work with existing SVN repositories. The differences are most likely minor yet made to appear grand (see here).

The one issue I recently had was with a 3-way merge. Bazaar was unable to track a VI which was merged. After the merge it thought that the existing file was deleted and a new one was generated with the same name, which wasn't quite what I was expecting. I was able to kludge it and find a work-around. I would be curious how well LabVIEW's merging VI could be integrated into Mercurial. This would be a key functionality for me.

[Jim Kring]

I am curious what you mean by something that can merge/branch worth a damn. Is this a LabVIEW problem or a general SCC issue?

What I mean is that SVN does not keep track of what's been already merged between branches. This makes it nearly impossible to maintain multiple branches (feature branches, developer branches, maintenance branches) and merge between them.

I would be curious how well LabVIEW's merging VI could be integrated into Mercurial. This would be a key functionality for me.

Yes, I'm curious too.

I think that LabVIEW's diff and merge support, while very nice to have, are still lacking. I would like to see them improved such that they could handle merging between two hierarchies of VIs (in memory concurrently), rather than just between two individual VIs.

Cheers,

[Jim Kring]

I've been doing a little more light research, but still haven't had a chance to dive in head-first.

I've found a great resource: Hg Init: a Mercurial Tutorial by Joel Spolskey. The first section, Subversion Re-education, is inspiring and makes me want to move forward.

However, I worry a lot about the fact that Mercurial keeps a copy of every revision (binary delta's it seems, thankfully) of every file in the repository on every developers machine. Since LabVIEW files are binary, this means that the repository might grow very large. The recommended strategy is to use a new repository for every project, rather than one big repository for all projects. However, it seems to me that as time goes by projects that have lots of binary (LabVIEW) files might grow very large and have many revisions, which will be too big a burden for developers.

That said, there's no better answer than testing it out on a real (hopefully, low-risk) project and seeing how it goes...

[Daklu]

That said, there's no better answer than testing it out on a real (hopefully, low-risk) project and seeing how it goes...

Keep us posted on what you find.

[Ton Plomp]

Keep us posted on what you find.

Man I like the Joel Spolsky document. I might try to convert my personal subversion repository in the coming week.

Ton

[PaulG.]

Subversion is being replaced?!?!

Die MONSTER, DIE!

[Ton Plomp]

Die MONSTER, DIE!

Oops sorry, but the story Joel Spolsky describes (fear to commit) sounds very familiar (even in a single person repo).
Another reason to go 'distributed' is the following:

I will be disconnected from my private SCC server for a few weeks and with Git I can still commit on a normal basis and re-sync when I get back.

Ton

[jdunham]

What I mean is that SVN does not keep track of what's been already merged between branches. This makes it nearly impossible to maintain multiple branches (feature branches, developer branches, maintenance branches) and merge between them.

I think that LabVIEW's diff and merge support, while very nice to have, are still lacking. I would like to see them improved such that they could handle merging between two hierarchies of VIs (in memory concurrently), rather than just between two individual VIs.

So what about all the SVN 1.5 changes for merge tracking? Have you tried to use them with your labview. I have to confess that I haven't tried, but it's on my list since it seems like these would go a long way toward fixing merge problems.

[Jim Kring]

So what about all the SVN 1.5 changes for merge tracking? Have you tried to use them with your labview. I have to confess that I haven't tried, but it's on my list since it seems like these would go a long way toward fixing merge problems.

Hi Jason,

I actually haven't played with the new merge tracking features in subversion 1.5 -- it's on my list, too. I figured I'd check out Mercurial first, to see about whether to jump to the next curve (Hg) rather than just taking an incremental step forward (svn 1.5). Plus, we use FogBugz as our bug tracker at JKI and Mercurial is part of the Kiln product companion to FogBugz -- so, it probably wouldn't be a difficult jump.

-Jim

[Ton Plomp]

Allright I made the move.
And even got the merging (allright it was a single file) working.
I've documented the settings in the LabVIEW Wiki: Mercurial

[Black Pearl]

I joined the crowd rushing after this strange element Hq. Seems like easy to learn/use.

When I was reading some introductions, I found that they warn to use it for large sets of binary data. Anyone yet experienced to say how it will work on real LV projects?
The other issue that still keeps me away from using it, is the merging process. As far as I understand Hq yet, merging is the very elemental interaction you would do. I'm stuck with a FDS, so no merging for me (except I write my own LV merge...). Will this be a show-stopper? Should I stay with SVN?

As a side-note, reading the manuals I discovered that it was my uncle who programmed the second SCC (and the first free one) called Revision Control System (RCS). I'm not sure if he is still into that...

Felix

[Jim Kring]

I joined the crowd rushing after this strange element Hq. Seems like easy to learn/use.

When I was reading some introductions, I found that they warn to use it for large sets of binary data. Anyone yet experienced to say how it will work on real LV projects?
The other issue that still keeps me away from using it, is the merging process. As far as I understand Hq yet, merging is the very elemental interaction you would do. I'm stuck with a FDS, so no merging for me (except I write my own LV merge...). Will this be a show-stopper? Should I stay with SVN?

As a side-note, reading the manuals I discovered that it was my uncle who programmed the second SCC (and the first free one) called Revision Control System (RCS). I'm not sure if he is still into that...

Felix

CVS is built on top of RCS, BTW.

[Black Pearl]

I checked his homepage, and he is researching on parallel programming. But using JAVA...

Ok, got enough topics for the next family come-together.

Felix

[Ton Plomp]

I did some digging and first I converted my large SVN repo (60 folders) into a large Mercurial Repo.
Then I found out I could not get a single folder with clone or pull.
Using the convert command and some LabVIEW voodoo I converted this into 60 subrepos in one main repository.
Works much faster and I can check out a single project.

Ton

[george seifert]

I did some digging and first I converted my large SVN repo (60 folders) into a large Mercurial Repo.
Then I found out I could not get a single folder with clone or pull.
Using the convert command and some LabVIEW voodoo I converted this into 60 subrepos in one main repository.
Works much faster and I can check out a single project.

Ton

Is there a way to check in/out directly from a LV project with Mercurial? Now that you've had it a few days do you think it's better than SVN?

George

[Ton Plomp]

Is there a way to check in/out directly from a LV project with Mercurial? Now that you've had it a few days do you think it's better than SVN?

George

Yes it is.

The main improvement for me is that I can commit when I am not in reach of my server.
that's the main difference, I can commit every day to my local (computer based) repository and when hitting a milestone (or just fixing a bug) push this my my own Mercurial server.

I like the system of Mercurial with webdir, which let you easily host multiple repositories on one computer, this keeps the code to get small.

On the down side I had issues with actually working together with someone else on a mercurial repository at Sourceforge. I am still not sure what happenend but we ended up with several heads that we didn't merge (actually we quit on that stage).

I am thinking about building a Mercurial provider for LabVIEW (hint, hint) so I can do the local stuff directly in the LabVIEW project.

Ton