SCC software

[Francois Normandin]

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?

[Tom Bress]

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?

[gmart]

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.

[jgcode]

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.

[crelf]

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.

[Francois Normandin]

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

Internally, NI uses Perforce. Perforce has a license model that is essentially free for a 2-user version.

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 , it doesn't seem to be prohibitively costly to buy licenses...

thanks for the tips.

[gmart]

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

[LAVA 1.0 Content]

QUOTE (Tom Bress @ Aug 12 2008, 03:34 PM)

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.

...

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

The issue about using SVN through the LabVIEW SCC interface is that SVN basiccally is the Merge routine. The MS SCC interface used by LabVIEW and PushOK is 'Check out, edit, check in' philosopy.

It works, quite good (for me) but I wouldn't use this bridge for professional work.

QUOTE (jgcode @ Aug 12 2008, 04:34 PM)

For multi developer work -

LV

integration is essential for smooth work IMO.

Yes, using the LV integration gives you power to build nice tools.

However the advanced functions (branching/labelling) needs to be done in the main SCC program.

Ton

[Scott Carlson]

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

[Francois Normandin]

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

Yes, using the LV integration gives you power to build nice tools.

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.

[crelf]

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.

[Francois Normandin]

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?

[crelf]

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

[Michael Aivaliotis]

Just a side note. If you are stepping on each other's toes so much that you need to always merge then your code is not designed well enough to allow multi-user development. Sorry. Either that or you have too many people working on the code.

[crelf]

QUOTE (Michael_Aivaliotis @ Aug 12 2008, 02:50 PM)

Just a side note. If you are stepping on each other's toes so much that you need to always merge then your code is not designed well enough to allow multi-user development.

True.

[jgcode]

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

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

[jdunham]

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?

[Tom Bress]

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?

[eaolson]

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?

[John Lokanis]

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

[jdunham]

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.

[crelf]

QUOTE (Tom Bress @ Aug 13 2008, 04: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?

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

[gmart]

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

[jdunham]

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.

[jgcode]

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

But even if you are a lone developer, you may find yourself merging.

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