Jump to content

Anyone using Mercurial for source code control in LabVIEW?


Recommended Posts

Success, lvdiff at least smile.gif The vital information was in that last pic, and at the VERY end of the readme.txt file in the lvdiff-folder. Thanks a lot by the way. Should be no big problem making this work in GIT either (edit:not true, there will still be problems with path names and stuff), but Mercurial looks and works much nicer in Windows anyway.

Edited by bsvingen
Link to comment
  • 6 months later...

I've been using Mercurial with TortoiseHG and Kiln (Kiln is free for two developers) since this last summer and I love it! It sometimes surprises me how easy some activities are compared to how I used to have to do them with VSS / Perforce / Surround SCM / DesignSync (don't ask about that one...:throwpc: ).

It is really easy to manage when I am the only developer, but also isn't too bad in a multi-developer environment either. The ability to go back to a tagged release, make a small change, perform a build and release (and tag), and then merge that change to the mainline is so easy in mercurial and next to impossible in the other environments I have used. It has literally saved me days of work because of how easy it is to manage releases, bug fixes, major changes with the branching and merging features. I have a major project where another developer is making sweeping changes that are not all backward compatible yet, but we are working from the same repository and I can still perform stable maintence releases. Meanwhile I have another branch where I am gutting the entire structure of the program.

The merging is a little lacking, but I am working on a simple tool to allow multi-file merges with TortoiseHG (LVMerge ends execution before the merge is actually complete and you miss the next file merge). A diff tool also needs a little work to support to diff changesets when multiple related files are different. Unfortunately LabVIEW's compile at edit time and sub vi dependency means that if multiple related files are different then the single file diff won't be entirely accurate. The only way I see is to use the Mercurial commands directly to "update" to each of the changesets being compared in their entirety and then compare them in different directly structures.

Merging doesn't seem to have this issue. I was thinking a hierarchy ordering of the vi's to merge might be necessary in order to get it correct, but LVMerge (at least in 2010) is very good. Now I just need to trick out the interface to "wait" until the merging is finished, cancelled, or errors out. Right now I just have a "next" button. Is anyone else working on an implementation of the "LVMerge" for mercurial that supports multi-file merging?

As far as an API for the project I don't really see a need except for maybe a hotkey shortcut to commit. One of the main reasons I think it is easier is that you don't have to "check in" and "check out" every file individually. I just make my updates for a certain feature or bug, then commit all files from explorer. When updating to different changesets you do have to revert all your files manually (I usually have everything closed when performing updates).

On a final note...no annoying "status" files in my working directory! thumbup1.gif

  • Like 1
Link to comment

I've been using Mercurial with TortoiseHG and Kiln (Kiln is free for two developers) since this last summer and I love it! It sometimes surprises me how easy some activities are compared to how I used to have to do them with VSS / Perforce / Surround SCM / DesignSync (don't ask about that one...:throwpc: ).

...snip...

Thanks for the great summary of your results and experiences with Mercurial/TortoiseHG/Kiln!

-Jim

Link to comment

Merging doesn't seem to have this issue. I was thinking a hierarchy ordering of the vi's to merge might be necessary in order to get it correct, but LVMerge (at least in 2010) is very good. Now I just need to trick out the interface to "wait" until the merging is finished, cancelled, or errors out. Right now I just have a "next" button. Is anyone else working on an implementation of the "LVMerge" for mercurial that supports multi-file merging?

As far as an API for the project I don't really see a need except for maybe a hotkey shortcut to commit. One of the main reasons I think it is easier is that you don't have to "check in" and "check out" every file individually. I just make my updates for a certain feature or bug, then commit all files from explorer. When updating to different changesets you do have to revert all your files manually (I usually have everything closed when performing updates).

I am working on an interface in the LabVIEW Project window (NI calls them Providers), as a set-top of my Mercurial API. I am working on the details, but the NI system is quite tricky!

Is the code for the full merge available somewhere so I could have a look?

Ton

Link to comment

I hope to have a alpha version ready by the end of today and posted. For right now I am just trying to get something that I can use to merge 10 files from two heads so I can get going on a project (also a good test case for this tool)...may not be the final implementation but maybe others may be interested in helping out.

;)

It is not a very large project so I don't know if I want to post it in the public domain of my Kiln site or not...

I'll let you know.

Link to comment

Sorry I got sidetracked with a "real" project. I think I am about ready to submit the merge tool, but I need some input on the best way to package / license it. I am thinking about just releasing it as an executable and possibly providing access to the source in a public kiln site. So would an EXE fall under BSD or GNU?

So I guess my questions are:

EXE? Installer?

What kind of license for an EXE?

Would a mecurial repository of a source distribution be ok for those that want to check out the code?

I also made a public fogbugz project for LVMergeHG so users can submit issues.

Link to comment

One thing to remember is that Mercurial itself is licensed as GPLv2+, this license includes the Mercurial logo. If you are just calling the Mercurial command line interface you don't need to use the GPLv2+ license.

Ton

<opening a can of worms>So, does that mean if you use the Mercuial logo in a VI icon that the VI must be licensed under GPLv2+?</opening a can of worms>

Link to comment

One thing to remember is that Mercurial itself is licensed as GPLv2+, this license includes the Mercurial logo. If you are just calling the Mercurial command line interface you don't need to use the GPLv2+ license.

Ton

It would make sense to use their logo as part of mine for the application, but didn't want to open that can of worms...

I am actually not even interfacing with Mercurial, only with LVMerge.exe and the Mercurial.ini file.

So would the BSD apply to an exe distribution? It is not really meant to run as source code, but as an interface application between TortoiseHG and LVMerge.

I am thinking GPLv2 might be the correct way to go anyway??? wacko.gif

Depending on how useful and how many features I can put in it I may want to charge for a full-featured version.

Also to be able to put it on the VI Package Network do I need to use VIPM to package it? I was going to just zip up an an install for it so it can auto configure the mercurial ini file to point to the program.

Let me know what you guys think. Thanks.

Working on the installer and icons now...

Link to comment

<opening a can of worms>So, does that mean if you use the Mercuial logo in a VI icon that the VI must be licensed under GPLv2+?</opening a can of worms>

Yes.

I posted a spinning mercurial logo (gif) to the Mercurial mailing list and got two very prompt responses, one of them was from Matt Mackal (main developer Mercurial) explicitly (but polite) telling that to use the logo you have to license it under a GPLv2+ license or have a written license from him that allows you to create a deriviative. The logo is posted here.

I explicitly asked him if I was calling the Mercurial command line only, then there is no need for a GPLv2 license and he acknowledged that.

I am actually not even interfacing with Mercurial, only with LVMerge.exe and the Mercurial.ini file.

I am thinking GPLv2 might be the correct way to go anyway??? wacko.gif

Let me know what you guys think. Thanks.

I've read up a little bit on the GPLv2 and it's not that hard of a license, and if you create an executable (thus stripping the icon of the VI) you should be able to use a more general license.

The nice thing of the GPLv2 is that it's in the spirit of OpenSource software, it enforces the next-generation of your source-code to be open source as well.

Ton

Link to comment

I've read up a little bit on the GPLv2 and it's not that hard of a license, and if you create an executable (thus stripping the icon of the VI) you should be able to use a more general license.

The nice thing of the GPLv2 is that it's in the spirit of OpenSource software, it enforces the next-generation of your source-code to be open source as well.

Ton

Thanks for the info on GPLv2. I went and read up on it as well. I am checking with legal as I created some of this tool while at my full time job. Need to find out about copyrights and if they will even allow me to post it. I'm pretty sure they will (they are not in the software business and this tool will not help their competitors). In the meantime I am going to test it with a couple versions of LabVIEW to make sure it is compatible. I've only been testing it with 2010. I've tested it on an XP Pro OS and a 64 bit VISTA (yeah!!! :yes: ). I don't have LabVIEW loaded on my Win7 machine but I am pretty sure it will install and work on Win7 if it worked on my VISTA box. I think it is ready for distribution, I just have to get the go ahead.

Thanks for your patience.

Link to comment
  • 2 weeks later...
  • 1 year later...

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.

A year has passed... Is Mercurial the next step in the progression: RCS » CVS » SVN » Hg ?

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.

Did you make the jump?

Should we be expecing a JKI TortoiseHg Tool for LabVIEWâ„¢? :D

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?

Is "working with large sets of binary data" an issue for LabVIEW users?

Do these tools address the Diff and Merge (et al) concerns?

Mercurial LabVIEW Integration

LVMergeHG

Mercurial API

Thanks!

Jason

Link to comment

In reverse order my opinion:

  • Mercurial API (developed by me) is an API to the mercurial command line interface, and does not handle merging or diffing, if you have set up diff properly, then the diff-vi will work.
  • LVMergeHG Looks promising, however I have not used it
  • Mercurial LabVIEW integration, works good for diffs and is very valuable if you want to see what changed in a file for a given changeset!

I'm working on a Project integration for Mercurial, however the LabVIEW provider for SCC is not the most stable.

Ton

Link to comment
  • 1 month later...

Has anyone been able to get merging to work with Labview 2011? I'm trying to make the switch from SVN to Hg. I'm using TortoiseHg and I really like the concept of how Hg works. I have LVDiff working but I'm struggling with merging. I've installed LVMergeHG and I have it specified as the tool to use for 3-way merging in the Hg global settings. When I open the TortoiseHg Workbench window I can see that I have a branch that I want to merge back into the main trunk. If I select the 'Diff to local..." option, LVDiff runs and I can see the to VI's I want to merge together. If I select the 'Merge with local" option I get a popup window, Prepare to merge, that shows info on the two VI's I want to merge. When I continue by clicking the 'Next' button I get the following:

% hg --repository C:\Documents and Settings\D\Desktop\ZZ merge --verbose --tool=internal:fail 6

resolving manifests

0 files updated, 0 files merged, 0 files removed, 1 files unresolved

use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon

[command returned code 1 Mon Apr 09 16:33:47 2012]

I can't see anything that looks like LVMerge is trying to run. I'm sure I'm probably doing some wrong or don't have something setup correctly. Any ideas?

Link to comment
  • 2 months later...

I'm tempted to make the switch from SVN to Hg. It seems it's easier to find a suitable online repository if your using Git or Hg (bitbucket). Ultimately I'm trying to make sure I always have access to my repository, even if I'm on another machine. I also like the idea of a separate local repo for each PC.

A couple of concerns:

1- Disc space. Yes I realize hard drives are cheap, but I'm sold on solid state drives and they are not.

2- Work flow. I'm sure this is just a matter of retraining myself on how I use Hg (Joels guide is a good start). I currently using TortoiseSVN, and I would probably use the equivalent for Hg, so that may not be a big change.

Is merging a huge advantage for Hg? I stay away from merging in SVN, admittedly because I've heard it doesn't work that well, but I didn't try it personally.

I think the main push for me to switch is to host my repository online. Since I'm going through this effort, it may be a good time to re-evaluate the source control provider. My current SVN repo is sitting at 8Gb (multiple projects). The plan would be to setup up multiple Hg repositories (one for each project) on bitbucket.

Any guides on how to convert the SVN repo to into several Hg repos?

Thoughts?

Edited by lvman
Link to comment
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

I've been thinking about this too, maybe we should get togeather. I reckon it would only take me about a week to do this, but I just need some spare time.

Link to comment

I've been thinking about this too, maybe we should get togeather. I reccon it would only take me about a week to do this, but I just need some spare time.

If you follow that thread and go to the last post, you can see that Ton has actually already released both the provider as well as the API in the Code Repository. So you just need to download it and give it a testdrive. :yes:

Link to comment

If you follow that thread and go to the last post, you can see that Ton has actually already released both the provider as well as the API in the Code Repository. So you just need to download it and give it a testdrive. :yes:

I saw that, but I need it to support normal SVN as well, but that's an easy fix.

Link to comment

I saw that, but I need it to support normal SVN as well, but that's an easy fix.

Well easy! ;) But the hardest part of getting the SCC Provider Interface figured out is indeed done. Interfacing SVN through the command line interface isn't too complicated but I was at some point looking to integrate it completely as DLL and that is quite a different story. Since it also is a potential maintenance nightmare I abandoned that approach completely. SVN does normally guarantee backwards compatibility for the SVN command line interface, but no such guarantee exists for the binary API.

Link to comment

If you have Mercurial as a client to SVN you can have the positive from Mercurial (local repository database), with the support for your legace/obsolete/accepted SVN repository.

I have never used this but Mercurial should be able to act as an SVN client.

Ton

Link to comment

If you have Mercurial as a client to SVN you can have the positive from Mercurial (local repository database), with the support for your legace/obsolete/accepted SVN repository.

I have never used this but Mercurial should be able to act as an SVN client.

Ton

Sounds very intersting.

I'm getting a new fresh version control server at work to play with and I'm very tempting to try Mercurial on that one.

Anybody having luck with moving over the repositoires and version history from SVN to Mercurial?

How good is Mercurial of handling LV files?

//Mike

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.