Borland StarTeam and LabVIEW

[Ed Dickens]

Has anybody used StarTeam with LabVIEW?

What I'm really wondering about is does it handle LabVIEW's file format better than MS VSS. Our company is considering switching from VSS to something else and StarTeam is the leading candidate because our biggest customer uses it.

Thanks

Ed

[Jim Kring]

Has anybody used StarTeam with LabVIEW?

What I'm really wondering about is does it handle LabVIEW's file format better than MS VSS. Our company is considering switching from VSS to something else and StarTeam is the leading candidate because our biggest customer uses it.

Thanks

Ed

Now's a great time to try to convince them to use subversion

Anything's better than VSS (not always, but you know what I mean).

[Ed Dickens]

Now's a great time to try to convince them to use subversion

Anything's better than VSS (not always, but you know what I mean).

We've already talked and looked into subversion. We haven't ruled it out yet, but we want to try a get everybody on the same system, and the majority of the company (they all code with words, it's really wierd ) is currently on VSS and most of them like it, or at least say it good enough for they use it for.

I guess the one big issue we're having with the CVS and why we just haven't made the switch is so far, our IT guy has not been able to get it up and running so we can try it. Though we've all been so swamped lately we really haven't had time to try and work the issues out.

Ed

[Jim Kring]

We've already talked and looked into subversion. We haven't ruled it out yet, but we want to try a get everybody on the same system, and the majority of the company (they all code with words, it's really wierd ) is currently on VSS and most of them like it, or at least say it good enough for they use it for.

I guess the one big issue we're having with the CVS and why we just haven't made the switch is so far, our IT guy has not been able to get it up and running so we can try it. Though we've all been so swamped lately we really haven't had time to try and work the issues out.

Ed

> I guess the one big issue we're having with the CVS and why we just haven't made the switch is so far, our IT guy has not been able to get it up and running so we can try it. Though we've all been so swamped lately we really haven't had time to try and work the issues out.

Sounds like organizational/cultural issues, not SCC issues . Also, if people like VSS, there are a variety of GUI's that have a VSS-like feel (explorer-style interface). Personally, I like SmartSVN (which is also cross-platform/Java). But for windows, there's no contest that TortoiseSVN is the best.

[crelf]

We've got multiple sites and a SCC database that you are using is often in another state. I use VSS on the server side and Source OffSite on the client side (it has a server-side broker). The client looks and feels a lot like VSS, but with a few extra features (a progress bar for one - why did they leave that out of VSS?!, as well as the ability to see full paths in the status window) and because it's a broker-based system, network outages don't corrupt your database (the broker talks to the DB and then serves everything, optionally encrypted, over the network to the client). So - if you are forced by an organizational restriction to use VSS on the server side, then SoS is an excellent option.

[Mike Ashe]

I've used Source Offsite as well, and had very good luck with it. Much better than VSS's builtin interface(s). That said, I'd second the TortoiseSVN vote.

[Jim Kring]

We've got multiple sites and a SCC database that you are using is often in another state. I use VSS on the server side and Source OffSite on the client side (it has a server-side broker). The client looks and feels a lot like VSS, but with a few extra features (a progress bar for one - why did they leave that out of VSS?!, as well as the ability to see full paths in the status window) and because it's a broker-based system, network outages don't corrupt your database (the broker talks to the DB and then serves everything, optionally encrypted, over the network to the client). So - if you are forced by an organizational restriction to use VSS on the server side, then SoS is an excellent option.

> So - if you are forced by an organizational restriction to use VSS on the server side, then SoS is an excellent option.

...or you can find an organization that strives to use the very best tools and is continuously improving its process.

[gmart]

Check out http://digital.ni.com/public.nsf/allkb/26e...625706e00743997. Starteam is on the list of providers that were tested with LabVIEW 8.0.

[Jim Kring]

Check out http://digital.ni.com/public.nsf/allkb/26e...625706e00743997. Starteam is on the list of providers that were tested with LabVIEW 8.0.

I would highly recommend not using LabVIEW's support for SCC API. It is a real pain to use, since it assumes a single repository per LabVIEW installation. Unfortunately, this only reflects reality for the LabVIEW R&D team at NI . For those of us on the outside, we typically have different repositories for each project, not to mention the possibility of different repository types (CVS, SVN, ClearCase, VSS) for each project.

[gmart]

Jim,

You are correct that currently LabVIEW 8.0 only allows global source control configuration. While this can be annoying to those that have different configuration per project , the usability of the source control integration is much better than what it was in 7.x. There are LabVIEW options such as prompting on edit of a VI, checking out callers during a check out, and so forth that can only be taken advantage of if you use source control in LabVIEW :thumbup: . There are many in R&D who want project level configuration. Those on the "inside" do work on multiple projects at one time as well, so the motivation to add this support is there. It'd be great to have your feedback on a project where global configuration is ok to have.

Regarding different repository types, users typically only use one repository type at a time since sites typically standardize on one source control provider. There are those who do need to switch between types, but they are the exception rather than the rule. I am not aware of an IDE that supports projects connecting to different providers. What I've seen is that IDEs, such as Visual Studio, use the default configured provider for the OS. They read this from a registry key and typically don't allow the user to change this (again going on the assumption that users typically will only use one repository at a time). That's not to say the feature would not be useful, just not typical.

[jpdrolet]

I would highly recommend not using LabVIEW's support for SCC API. It is a real pain to use, since it assumes a single repository per LabVIEW installation. Unfortunately, this only reflects reality for the LabVIEW R&D team at NI . For those of us on the outside, we typically have different repositories for each project, not to mention the possibility of different repository types (CVS, SVN, ClearCase, VSS) for each project.

I don't know about 8.0 but in previous versions you indeed can have different SCC settings per project, provided you set a different default(home) directory for each project. The file scccfg.ini is stored in the default directory which defaults to LabVIEW directory.

Having distinct project default directories is conveniently done using a labview.ini file per project and start LabVIEW for a given project using a shortcut with the -pref switch setting the ini file.

Personally I use custom file extensions to LabVIEW pref files ( *.lv7ini, *.lv71ini) so I can start a project with the right pref file and LabVIEW version with a double-click on the pref file.

[Jim Kring]

Jim,

You are correct that currently LabVIEW 8.0 only allows global source control configuration. While this can be annoying to those that have different configuration per project , the usability of the source control integration is much better than what it was in 7.x. There are LabVIEW options such as prompting on edit of a VI, checking out callers during a check out, and so forth that can only be taken advantage of if you use source control in LabVIEW :thumbup: . There are many in R&D who want project level configuration. Those on the "inside" do work on multiple projects at one time as well, so the motivation to add this support is there. It'd be great to have your feedback on a project where global configuration is ok to have.

Regarding different repository types, users typically only use one repository type at a time since sites typically standardize on one source control provider. There are those who do need to switch between types, but they are the exception rather than the rule. I am not aware of an IDE that supports projects connecting to different providers. What I've seen is that IDEs, such as Visual Studio, use the default configured provider for the OS. They read this from a registry key and typically don't allow the user to change this (again going on the assumption that users typically will only use one repository at a time). That's not to say the feature would not be useful, just not typical.

Maybe LabVIEW's feature set is definining what users typically do with LabVIEW. Unnecessary coupling that is the product of legacy will only help you hold on to the past and keep you from moving forward.