Jump to content


Photo
* * * * * 1 votes

Anyone using Mercurial for source code control in LabVIEW?


  • Please log in to reply
53 replies to this topic

#1 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,923 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 12 February 2010 - 05:32 AM

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,

#2 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Members
  • PipPipPipPipPipPip
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 12 February 2010 - 06:47 AM

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 Im still learning how to do relatively basic things in git, I learned pretty much all of hgs functionality in about a day. If youre familiar with Subversion, transitioning to Mercurial should be a piece of cake the functions youre 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

#3 Gary Rubin

Gary Rubin

    The 500 club

  • Members
  • PipPipPipPipPip
  • 628 posts
  • Location:Northern Virginia, USA
  • Version:LabVIEW 8.6
  • Since:1997

Posted 12 February 2010 - 03:35 PM

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.

#4 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,923 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 12 February 2010 - 05:49 PM

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,

#5 harbenger

harbenger

    I want a LabVIEW icon under my name!

  • Members
  • 3 posts
  • Version:LabVIEW 2009
  • Since:2005

Posted 12 February 2010 - 07:53 PM

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.

#6 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,923 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 12 February 2010 - 08:41 PM

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,

#7 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,923 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 17 March 2010 - 07:20 AM

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

#8 Daklu

Daklu

    Bringing the Fu to you

  • Premium Member
  • 1,830 posts
  • Location:Seattle
  • Version:LabVIEW 2009
  • Since:2006

Posted 18 March 2010 - 05:13 AM

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.

Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.

Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.

There are two secrets to success:
Secret #1 - Never tell everything you know.


#9 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Members
  • PipPipPipPipPipPip
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 18 March 2010 - 05:12 PM

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

#10 PaulG.

PaulG.

    The 500 club

  • Members
  • PipPipPipPipPip
  • 833 posts
  • Location:Greater Metro Detroit, MI, USA
  • Version:LabVIEW 2011
  • Since:1998

Posted 18 March 2010 - 07:21 PM

Subversion is being replaced?!?! Posted Image Posted Image Posted Image Posted Image Posted Image Posted Image Posted Image Posted Image

Die MONSTER, DIE!
"'Value-added data'? What is that? Numbers fortified with art"? -Jon Stewart

#11 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Members
  • PipPipPipPipPipPip
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 18 March 2010 - 07:55 PM

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

#12 jdunham

jdunham

    Extremely Active

  • Members
  • PipPipPipPipPip
  • 628 posts
  • Location:San Francisco, CA
  • Version:LabVIEW 2011
  • Since:1994

Posted 22 March 2010 - 10:42 PM

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.

#13 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,923 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 23 March 2010 - 04:45 AM

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

#14 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Members
  • PipPipPipPipPipPip
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 27 March 2010 - 06:54 PM

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

#15 Black Pearl

Black Pearl

    Extremely Active

  • Members
  • PipPipPipPip
  • 410 posts
  • Location:Freiburg, Germany
  • Version:LabVIEW 7.1
  • Since:2002

Posted 20 April 2010 - 07:02 PM

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

#16 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,923 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 20 April 2010 - 08:21 PM

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

#17 Black Pearl

Black Pearl

    Extremely Active

  • Members
  • PipPipPipPip
  • 410 posts
  • Location:Freiburg, Germany
  • Version:LabVIEW 7.1
  • Since:2002

Posted 20 April 2010 - 08:40 PM

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

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

Felix

#18 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Members
  • PipPipPipPipPipPip
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 25 May 2010 - 06:37 AM

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

#19 george seifert

george seifert

    Extremely Active

  • Members
  • PipPipPipPip
  • 401 posts

Posted 02 June 2010 - 03:46 PM

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

#20 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Members
  • PipPipPipPipPipPip
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 02 June 2010 - 07:30 PM

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