Jump to content

LabVIEW Source Control Provider


Recommended Posts

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

Link to comment
  • 5 months later...

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

Link to comment

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

Link to comment

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.

Link to comment
  • 1 month later...

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

Link to comment
  • 7 months later...

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.

Link to comment
  • 10 months later...

Join the conversation

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

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.