LabVIEW Source Control Provider

[Ton Plomp]

I am thinking about creating a mercurial Source Control Provider client.

I have created a new provider based on the existing Perforce.

If I copy this in the Provider folder of LabVIEW I get an extra provider in the SCC options dialog.

However selecting the new provider causes an error.

Does anyone have some pointers about the setup of this provider feature?

Ton

[Fab]

Now that several months have gone by, how do you feel about Mercurial?

I use Fogbugz too and I just went to their Fogbugz and Kiln world tour and the link between Fogbugz, Kiln and Mercurial seemed very promising. But since LabVIEW handles binary files I don't know how useful it is going to be.

I have been using TortoiseSVN and I gave up long time ago on branches and merges. It was a nightmare, the Fogcreek guys made it sound like in Mercurial this was not an issue and they use TortoiseHg, which would make the transition easy. I will just need to remember that there is an extra layer involved and push/pull needs to be done besides the commit/update. They also mentioned a tool that converts a SVN repository into a Hg repository.

Anyway, before going on this "adventure", I wanted to make sure I asked you guys how it has been working for you. Should I stay on SVN? or jump on Mercurial?

Thanks,

Fab

[Ton Plomp]

Now that several months have gone by, how do you feel about Mercurial?

Pretty good.

I am still working on a Mercurial API, together with a Source Control Provider. (I think I finished it almost)

One of the best things is that it's quite easy to set up a public mirror of your repo's.

For instance when I develop a tool, I normally push to my private server, but once every release I push to my private server and to a public server where people can get a clone of the history.

Your right that the size of a LabVIEW repo is substantial (there is no compression possible in the latest LabVIEW versions) and every changed VI is stored as is.

Ton

[Black Pearl]

Ton,

I'll propably start using Hq for a project next week (currently under SVN). How do you interface Hq from LV? Using SystemExec/CommandLine?

I was thinking about checking a vi automatically in a local repository when saved.

Felix

[jdunham]

I have been using TortoiseSVN and I gave up long time ago on branches and merges. It was a nightmare, the Fogcreek guys made it sound like in Mercurial this was not an issue and they use TortoiseHg, which would make the transition easy. I will just need to remember that there is an extra layer involved and push/pull needs to be done besides the commit/update. They also mentioned a tool that converts a SVN repository into a Hg repository.

Anyway, before going on this "adventure", I wanted to make sure I asked you guys how it has been working for you. Should I stay on SVN? or jump on Mercurial?

Branches and merges should get a lot better with LV2010 if you separate the compiled code out of the VI file. However, merging may never be easy. Anyone who uses SVN or Hg with text-based languages is not going to have much guidance for us graphical coders. I don't think Hg is a silver bullet and it's quite possible that it may lead to more frequent and more difficult merges of your graphical code.

[Ton Plomp]

Ton,

I'll propably start using Hq for a project next week (currently under SVN). How do you interface Hq from LV? Using SystemExec/CommandLine?

I was thinking about checking a vi automatically in a local repository when saved.

Felix

Yes, I use the default mercurial (HG) commands to interface with Mercurial.

Branches and merges should get a lot better with LV2010 if you separate the compiled code out of the VI file. However, merging may never be easy. Anyone who uses SVN or Hg with text-based languages is not going to have much guidance for us graphical coders. I don't think Hg is a silver bullet and it's quite possible that it may lead to more frequent and more difficult merges of your graphical code.

Removing the compiled code from the VI definitely creates less merges. But the LabVIEW merge utility (LVMerge) is quite good.

And yes, Mercurial is no silver bullet in this case, it is however important to limit the number of branches and merges (but that goes for textual code as well).

Ton

[Timmar]

Branches and merges should get a lot better with LV2010 if you separate the compiled code out of the VI file. However, merging may never be easy. Anyone who uses SVN or Hg with text-based languages is not going to have much guidance for us graphical coders. I don't think Hg is a silver bullet and it's quite possible that it may lead to more frequent and more difficult merges of your graphical code.

I have used a workaround to solve this problem:

Create a substitute drive from the project root and work from it.

The catch is that some source control packages don't recognize the files.

Clearcase works.

[Bean]

For reference, this was solved / contributed by Ton:

Mercurial Provider

Mercurial API