Integrated Source Control doesn't honor given username after restart of LabVIEW

[whimboo]

I don't really like the integrated Source Control of LabVIEW 8.20 due to some missing features and failures which happen. But for a presentation I had to get some practical information. As SCC API provider I selected Microsoft Visual Source Safe for an example project. While playing around I noticed following bug in the implementation for LabVIEW.

All given information to access the SCC provider is saved inside 'labview.ini' (which is IMO not the correct place, especially when you are working with different projects). As user I selected 'admin' and not the logged on system user. Access to the repository is granted within the current session and I can do all operations. But if you restart LabVIEW it cannot access the repository because it uses the system user and not the given username to log into the repository.

If you wan't to work with the integrated Source Control each user who should get access to the repository should have an own user account with the same username as his Windows account.

This is one of a number of bugs since a couple of versions which don't let me use the integrated Source Control.

Henrik

[gmart]

I have used a non-system user name successfully with Visual SourceSafe. One issue that has come up with SourceSafe is that it does not remember a non-system user's password between sessions. This seems to be a limitation with the interface that Visual SourceSafe exposes. So perhaps the issue you are seeing is that admin has a password (which is usually the case) and therefore when LabVIEW restarts, the SourceSafe interface requires the password (yet doesn't prompt for one, go figure). There is an option in the SourceSafe admin tool - "Use network name for automatic user log in" which may be related to this. I believe for now, your recommendation of having a user account with the same name as the system user is the workaround.

Regarding the other bugs you mentioned. If you have seen problems, please report them so that the integration can be improved.

[whimboo]

The described problem only occurs for non system users. If I set a different password for my system user, access to SourceSafe is granted also over different sessions in LabVIEW. If I disable "Use network name for automatic user log in" I didn't get a dialog to specify user and password.

LabVIEW still reports following error which is an invalid source control reference:

Error -2976 occured at
SCC_Item_Init.vi.ProxyCaller

> If you have seen problems, please report them so that the integration can be improved.

I've send one or two of them already as bug report directly to NI some time ago. So they already know these issues.

[Marco_Brauner]

Hi,

I try to get back on this question because I´m not sure if it has been already handled to your satisfaction.

gmart mentioned a workaround

the workaround is "I believe for now, your recommendation of having a user account with the same name as the system user is the workaround."

Is this helping you out?

You said you have already told our R&D about this problem. Is there any document or link you can give me?



best regards

Marco Brauner

[whimboo]

I talked with our local distributor about this problem a while ago. But it seems that the issue wasn't forwarded. No response till now. I created a Service Request before some minutes. I think this will be seen. I've linked to this thread.

The problem is solved for me because I don't use the integrated source control anymore. From now on I trust an external application (Subversion) which gives me better control.

Henrik

[Marco_Brauner]

Hi Hendrik,

ok, subversion is a good choice. But what I must note is, because you talk about Microsoft Source Safe as ".. LabVIEW builtin SCC..", that this
is not a NI Product and thus an external SCC. Since LV 8 we don´t provide any builtin SCC-solution anymore.
The interface that MS SS exposes is limited and only this can be integrated into LV 8.


best regards

Marco Brauner

[whimboo]

Yes, I know. Perhaps my last message wasn't clear enough but what I ment was that LabVIEW only can use souce control applications which offer it services over the SCC API. And all the checkin/checkout stuff is done by LabVIEW itself by providing menu and context menu items. The user doesn't have to know anything about the background of source control and is limited as well.

There are a lot of things to fix until the integraded source control is comfortable enough.

[gmart]

---

@whimboo wrote:

There are a lot of things to fix until the integraded source control is comfortable enough.

---

You have mentioned before that you've reported some issue with LabVIEW's source control. Previously you mentioned that you reported "one or two" issues. Now you say there are "a lot of things to fix". It would be interesting to know what deficiencies there are in  your mind that are giving the impression that the integration is not "comfortable". Some of it may be that since the interface is generic, more advanced features are not available. Those can't be helped. But other issues may be under LabVIEW's control.

[whimboo]

Due to following items I don't want to work with the integrated source control:

1. All SCC options are stored inside the file 'labview.ini'. That makes you unimpossible to work with different projects without reconfiguring the SCC again and again. Each project should hold it's own SCC options which overrides the LabVIEW global SCC options. If you are working without projects the global SCC options should be used.

2. If you don't have access to the repository (e.g. network disconnected) you get an error message each time you open a vi (last tested with 8.0 a long time ago). LabVIEW should silently fail and give me at maximum one alert that the connection to the repository cannot be established. Opening the SCC options you can see that everyting is resetted while the correct configuration is still located inside the 'labview.ini'. You have to delete them manually inside the configuration file.

Both parts are already reported to NI in february last year.

3. Comparing two different versions of one file is not working unless you compare the current local version with the latest version inside the repository. Using subversion I can do that by integrating metadiff and lvdiff. It is more than helpful.

4. You have to use an external scc client to create a branch or tag.

5. That's a personal thing but I like the way of using update/commit instead of checkout/checkin.

Dunno if I remember all the things I missed while testing the integrated source control some time ago.

Henrik

[gmart]

Thank you for your response. It was very helpful in understanding your concerns with the integration. The intent of the source control integration in LabVIEW is to allow you to perform basic source control actions without the need to go to the provider's client. Since your first two concern were reported, hopefully they should be addressed in a future LabVIEW release. Regarding your other points:

3. Comparing files to their latest versions is the supported mechanism in LabVIEW. Some providers allow comparisons to arbitrary versions in their File History dialogs. Also, you can setup lvdiff within your provider and when you compare files in LabVIEW, it should be called to perform the compare.

4. Branching and tags are considered advanced features an are not supported in LabVIEW.

5. Checkout/Checkin is the standard way most providers works. Subversion has a different model which if you're comfortable with, is completely acceptable.

Since you've determined it makes sense to work with source control outside of LabVIEW, stick with it. The tools are there in LabVIEW to use if they are appropriate to you development style and workflow.