Jump to content

SCC software


Recommended Posts

I'm contemplating the idea of using SCC for my (rather small) development projects and would like to know which SCC software people are using out there. There's a list of supported SCC programs on NI website but I have no clue which ones are better suited for LabVIEW projects.

Corrolary question: Are there any good open-source SCCs?

Link to comment
  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

I use Subversion and TortoiseSVN, both of which are open source. Subversion does the actual source code control and TortoiseSVN lets you access the Subversion SCC functions on your desktop through the mouse right-click menus. I've found SCC to be extremely useful even as a solo developer.

The list on the NI website says that you need a low-cost third-party plug in to use Subversion with LabVIEW, but this statement is incomplete and somewhat misleading. What it means is that if you want to access the SCC functionality of Subversion from within the LabVIEW development environment then you need a plug-in. But if you read Jim Kring's blog posts on the subject, as well as the comments of others in the LAVA forums, I think you'll see that the beauty of using TortoiseSVN is that you DON'T do your SCC from inside LabVIEW. TortoiseSVN makes it easy to do your SCC from your desktop without opening an SVN client program. Bottom line: you can use Subversion and TortoiseSVN for free, effective SCC without any other plug-ins or programs.

One last point: be aware that there are two different SCC philosophies out there. One is a rigid "Check out, edit, check in" model that prevents two developers from ever working on the same file at the same time. The other is an "Edit and merge" philosophy where two developers can work on the same file at the same time, with the software managing a merge of the two files if possible. The "Edit and Merge" philosophy seems to be more popular among practicing developers. Subversion supports both models, but the default is the edit and merge behavior. LabVIEW itself provides Merge functionality that can be used by Subversion. Some people try Subversion expecting the other kind of behavior and think that it is broken when it allows two people to work on the same file simultaneously.

QUOTE (normandinf @ Aug 12 2008, 09:02 AM)

I'm contemplating the idea of using SCC for my (rather small) development projects and would like to know which SCC software people are using out there. There's a list of supported SCC programs on NI website but I have no clue which ones are better suited for LabVIEW projects.

Corrolary question: Are there any good open-source SCCs?

Link to comment

QUOTE (Tom Bress @ Aug 12 2008, 07:34 AM)

The list on the NI website says that you need a low-cost third-party plug in to use Subversion with LabVIEW, but this statement is incomplete and somewhat misleading. What it means is that if you want to access the SCC functionality of Subversion from within the LabVIEW development environment then you need a plug-in. But if you read Jim Kring's blog posts on the subject, as well as the comments of others in the LAVA forums, I think you'll see that the beauty of using TortoiseSVN is that you DON'T do your SCC from inside LabVIEW. TortoiseSVN makes it easy to do your SCC from your desktop without opening an SVN client program. Bottom line: you can use Subversion and TortoiseSVN for free, effective SCC without any other plug-ins or programs.

The text in the knowledge base states This integration enables LabVIEW users to access the source control providers from within the LabVIEW development environment. That statement does not imply that you can't use external tools to perform source control (as is done with Tortoise). Also, using the integration in LabVIEW gives you functionality such as prompting to check out on edit that you wouldn't get by using an external tool.

The selection of an SCC provider depends on your needs balanced with cost. SVN is a good package and is very popular in this forum. Internally, NI uses Perforce. Perforce has a license model that is essentially free for a 2-user version.

Link to comment

QUOTE (gmart @ Aug 12 2008, 10:24 PM)

The selection of an SCC provider depends on your needs balanced with cost. SVN is a good package and is very popular in this forum. Internally, NI uses Perforce. Perforce has a license model that is essentially free for a 2-user version.

I am moving to Perforce for personal LabVIEW use due to the 2-user freebie.

Currently work uses Microsoft VSS, but we are looking closely at Perforce and apparently making a switch.

Extra licences are ~ AU$1K mark I have been told.

As a side note during testing we were able to migrate our VSS database easily - as there is some Perl script written by Perforce that allows you to transfer all info from a VSS DB into Perforce.

For multi developer work - LV integration is essential for smooth work IMO.

Link to comment

QUOTE (Tom Bress @ Aug 12 2008, 09:34 AM)

I use Subversion and TortoiseSVN, both of which are open source. Subversion does the actual source code control and TortoiseSVN lets you access the Subversion SCC functions on your desktop through the mouse right-click menus. I've found SCC to be extremely useful even as a solo developer.

We use Subversion + TortoiseSVN across our whole company (not just for software SCC) and are very happy with it.

Link to comment

QUOTE (gsmart @ Aug 12 2008, 10:24 AM)

QUOTE (jgcode @ Aug 12 2008, 10:34 AM)

I am moving to Perforce for personal LabVIEW use due to the 2-user freebie.

...

For multi developer work -
LV
integration is essential for smooth work IMO.

Well, if NI uses Perforce and it's free for 1 or 2 users, than I might as well start fresh with it. Should our team grows to more than 1 developer :P, it doesn't seem to be prohibitively costly to buy licenses...

thanks for the tips.

Link to comment

QUOTE (crelf @ Aug 12 2008, 09:22 AM)

We use Subversion + TortoiseSVN across our whole company (not just for software SCC) and are very happy with it.

What would be nice is if some enterprising individual were to write an SVN plugin for LabVIEW. Then all would be right with the world :D

Link to comment

QUOTE (normandinf @ Aug 12 2008, 09:02 AM)

I'm contemplating the idea of using SCC for my (rather small) development projects and would like to know which SCC software people are using out there. There's a list of supported SCC programs on NI website but I have no clue which ones are better suited for LabVIEW projects.

Corrolary question: Are there any good open-source SCCs?

Subversion and TortoiseSVN . If you take this route, we are around for further questions.

-src

Link to comment

QUOTE (Ton @ Aug 12 2008, 11:34 AM)

That's what got me thinking it was time to implement SCC for me... How else can I try this Project Scanner if I don't use SCC?

QUOTE (Scott Carlson @ Aug 12 2008, 11:39 AM)

Subversion and TortoiseSVN . If you take this route, we are around for further questions.

-src

Subversion and TortoiseSVN seems to be a very popular choice. I'll have to try it too.

I'm a big open source fan.

Link to comment

I think integration into the LabVIEW project is overrated. Our engineers do far more than project-specific work, so the TortoiseSVN client that integrates SCC into Windows Explorer is an absolute God-send for us (we were using VSS previously). I suppose it would be nice to use the project integration, but that would give us more than one place to do the same thing, so it makes it fundamentally less intuative. I know that you can have non-LabVIEW files in the project, but that's not what I'm talking abou there.

As for the check-in/check-out vs merge philosophies (a really good point and important for consideration when you're first considering implimenting a SCC schema) - they are very different and equally valid, so it's really a choice depending on your situation. We reviewed both paradigms and chose the former due to several reasons. I'm not saying that that option is inherently better, but it's more appropriate for our situation.

Link to comment

QUOTE (crelf @ Aug 12 2008, 11:55 AM)

As for the check-in/check-out vs merge philosophies (a really good point and important for consideration when you're first considering implimenting a SCC schema) - they are very different and equally valid, so it's really a choice depending on your situation. We reviewed both paradigms and chose the former due to several reasons. I'm not saying that that option is inherently better, but it's more appropriate for our situation.

I would think check-in/check-out is better for my needs, as I'm a lone wireworker at the moment.

Can these SCC schema be changed at a later date or is the initial choice final?

Link to comment

QUOTE (normandinf @ Aug 12 2008, 11:54 AM)

I'm a big open source fan.

Me too, but whilst I like the whole open source idea, it only works when the project output is useful, robust and appropriately supported. For Subversion and TortoiseSVN, my experience is that's absolutely the case :yes:

Link to comment

QUOTE (crelf @ Aug 12 2008, 11:55 PM)

I think integration into the LabVIEW project is overrated. Our engineers do far more than project-specific work, so the TortoiseSVN client that integrates SCC into Windows Explorer is an absolute God-send for us (we were using VSS previously). I suppose it would be nice to use the project integration, but that would give us more than one place to do the same thing, so it makes it fundamentally less intuative. I know that you can have non-LabVIEW files in the project, but that's not what I'm talking abou there.

From my experience - using VSS external to the project means there is alot of copies around :angry:

As I generally have to check out the whole project each time I have to work on it - rather than a specific file and required dependencies I need to code.

Also ideally there should be strict rules in place for check in check out daily, but alas that is not the case by the people in power.

I have seen the ill effect of multiple versions (I took over someones role who did not check in check out :nono: ) I found versions of version of versions around the place. It was a freaking nightmare for us and the client.

Therefore something that enforces their developers to check in/out must be a good thing from a manager's point of view?

From testing the integration I was very impressed.

I can visually see whilst working on from the Project what is checked in and checked out.

I can easily and quickly check something out that I need - working in the same environment as I program in.

And I can easily check a change back in - no manual drag and drop to a third party app.

I like it! :thumbup:

I find this method more intuative for me.

Link to comment

Our group has several developers and over 3000 VIs, and we are using SVN with no SCC integration and using a copy/merge model rather than check-in/check-out. On the whole it works well, but merging can really be a pain. We have some custom tools for ignoring recompiles in a merge, but it can be a headache. I also wrote my own tool with similarities toTon's project scanner (No fancy gui or anything). I'd rather scrap that and use a LAVA open source tool.

I would be interested in opinions about whether a switch to check-in/check-out would be useful (Sorry to hijack the thread somewhat). The benefit would be the SCC integration (PushOK) and the project scanner and any LVProj support, and the risk would be that working on the merge model for so long (4 years) would make the changeover too difficult for the team.

How does the SCC plug-in handle times when you change a typedef and several hundred VIs automatically recompile?

Link to comment

QUOTE (normandinf @ Aug 12 2008, 12:01 PM)

I would think check-in/check-out is better for my needs, as I'm a lone wireworker at the moment.

Can these SCC schema be changed at a later date or is the initial choice final?

If you are a lone wolf then I would recommend the edit-merge. Since you are the only one working on a given file, you'll never have to merge and you'll avoid having to check files in and out. Why check them in and out if you are the only one working on them?

Link to comment

QUOTE (Tom Bress @ Aug 13 2008, 03:58 PM)

If you are a lone wolf then I would recommend the edit-merge. Since you are the only one working on a given file, you'll never have to merge and you'll avoid having to check files in and out. Why check them in and out if you are the only one working on them?

I, too, am a lone wolf. I've been using SVN and TortoiseSVN for a couple of years now and wonder how I ever lived without it. I'm just not quite clear on the difference between edit-merge and check-in/check-out. Could someone explain a bit?

Link to comment

I have been using Perforce for several years now with LabVIEW. I think it is the best SCC out there. I have tried VSS, CVS, PVCS and SVN. The thing I like best about Perforce is the ability to have a UI to manage my files. I do not like the 'itegration' of SVN into the windows explorer. Perforce does this too, but I almost never use it.

I do like the integration of an SCC into the LV Project. Mainly because when I create a new VI, it prompts me to add it to Perforce. I use the Perforce GUI to do my checkins, however.

There are some things about Perforce that I do not like, but overall IMHO it is the best in breed.

As for using SCC with LabVIEW, I do find that I keep all the fiels in the project checked out to me when doing major work. This way, I can freely edit and recomiple VIs as needed. When I am ready to checkin the changes, Perforce will do a DIFF and give me a list of all changed files so I can add my comments to each and submit them.

In our group, we usually only have one DEV working on a Project or sub-project at a time, so this method works well. YMMV.

-John

Link to comment

QUOTE (Tom Bress @ Aug 13 2008, 01:58 PM)

If you are a lone wolf then I would recommend the edit-merge. Since you are the only one working on a given file, you'll never have to merge and you'll avoid having to check files in and out. Why check them in and out if you are the only one working on them?

I totally agree that if you are working alone, you don't need any kind of locking (check-in/check-out)

But even if you are a lone developer, you may find yourself merging. If you have a certain snapshot (SCC revision) which is known to work, and maybe you've released it to someone who is paying you money, you should always tag that. Then you can do new development in your main version (the trunk), breaking the system horribly. If the end-user needs a small fix, you make a branch from your tag, release the update right away, and then merge your fixes back into the trunk when you have the time.

In Subversion there is no difference between a branch and a tag, but to stay sane, you should keep them separate, and never edit source code in the tag area. Any fixes should happen in your branch area.

Link to comment

QUOTE (Tom Bress @ Aug 13 2008, 04:58 PM)

That's a really good point.

QUOTE (eaolson @ Aug 13 2008, 05:27 PM)

I'm just not quite clear on the difference between edit-merge and check-in/check-out. Could someone explain a bit?

It's called the "concurrency model" or "management model" of the SCC system. You can read more about the different paradigms here (there are more than just locking and merging, but they are by far the most common).

Summary from that page:

File locking: ...lock files so that only one developer at a time has write access to the central "repository" copies of those files. Once one developer "checks out" a file, others can read that file, but no one else is allowed to change that file until that developer "checks in" the updated version (or cancels the checkout).

Version merging: ...allow multiple developers to edit the same file at the same time. The first developer to "check in" changes to the central repository always succeeds. The system provides facilities to merge changes into the central repository, so the changes from the first developer are preserved when the other developers check in.

Physically merging text-based code is inherently easier than merging LabVIEW code (although excellent tools like LVDiff make it a little easier to manually merge).

Link to comment

QUOTE (jdunham @ Aug 13 2008, 02:49 PM)

How does the SCC plug-in handle times when you change a typedef and several hundred VIs automatically recompile?

There is an option in Tools>>Options>>Source Control where LabVIEW will include a list of callers of a VI that are in memory when checking out a file. So in your example, when you check out your typedef, if the callers of the typedef are in memory, those will be added to the list of items to check out. Something to be aware of. By default, the source control dialog box is not displayed during a check out operation. So when callers are in memory, you may get a warning dialog stating that other files will be checked out. If you do show the dialog box, the callers will be listed in the dialog box. The same behavior happens for subVIs (for the use case where you change the connector pane configuration for example).

Link to comment

QUOTE (gmart @ Aug 13 2008, 03:15 PM)

There is an option in Tools>>Options>>Source Control where LabVIEW will include a list of callers of a VI that are in memory when checking out a file. So in your example, when you check out your typedef, if the callers of the typedef are in memory, those will be added to the list of items to check out. Something to be aware of. By default, the source control dialog box is not displayed during a check out operation. So when callers are in memory, you may get a warning dialog stating that other files will be checked out. If you do show the dialog box, the callers will be listed in the dialog box. The same behavior happens for subVIs (for the use case where you change the connector pane configuration for example).

So If I don't want to check out the callers, because I don't want to recompile just yet, can I get any work done, or will I constantly be asked to save changes every time one of the callers leaves memory?

I think that has kept me from making this transition so far. I want to delay saving for any VI which didn't see a real change so that I can limit my SVN check-in to the files which I actually worked on. Once I save the recompiles it's very difficult to track which VIs have changes that matter and which don't. I only want to check in VIs with true human-initiated changes, so that I can minimize conflicts with my co-workers, and I can figure out which VIs were edited if there is a new bug.

If I save every VI that wants to be saved and check in all the "changes", then merging with other branches is very, very difficult. My current solution to this is to refuse to save VIs which I haven't personally modified, but I have to say it's a pain in the neck.

I suspect the SCC stuff doesn't help with this, but I would like to raise awareness and hold out some slim hope that others have solved this a bit more elegantly.

Link to comment

QUOTE (jdunham @ Aug 14 2008, 05:37 AM)

Even for a lone-developer this is a really important point. You should ALWAYS have a working version of the code available.

Even if you continually doing a branch, merge, branch, merge for changes - this is way safer as jdunham mentioned: especially with paying customers.

QUOTE (jdunham @ Aug 14 2008, 05:37 AM)

I totally agree that if you are working alone, you don't need any kind of locking (check-in/check-out)

I don't agree 100% with this comment. More correctly IMO the logic should be:

1 developer, 1 OS = no check in/out

As I lone user you can be programming on multiple workstations. As a lone developer I use a laptop & a PC. Throw in a high usage of virtual machines on the PC and now I have alot of potential copies. Granted I usually stick to one OS normally there is still potential for copies.

Hence the reason I am looking to go to Perforce and run it off my server and use check in/check out. I just makes sense to me. Having been stung by the above two points (hey its all a learning curve for me) :rolleyes: .

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