LabVIEW Developers Feature Brainstorming

[gmart]

The interface available to do this is not consistent across all providers. Some providers do not support a native Rename function. So in those cases, we could remove the original file and then add the new one to the repository, but then what if you wanted to keep the history of the previous file? Branching is not supported at all through the generic interface that is used so that functionality cannot be done. For this reason, we considered a source control Rename an advanced feature. So we decided that renaming source control file, while useful functionality in LabVIEW, needs to be done from the provider's client.

What I typically do is have the files open in LabVIEW and then do a rename from my SCC provider. Then back in LabVIEW, I do a Save As to the same location where the file was renamed via the provider's client.

[whimboo]

There is no real improvement for me with the new LabVIEW 8.5 on SCC basis. The project SCC settings still need a globally defined SCC provider. That's why I can't use the built-in Source Control features. I'm working on different projects which don't have the same provider. One old project is still using Visual Source Safe while newer ones are versioned by SVN. If I switch between projects I still would have to change the global settings each time. I agree that all the SCC configuration should happen within the project settings and that they don't need or overwrite globally defined settings. Until this isn't fixed I won't switch to the built-in feature. I'm running fine with TortoiseSVN.

Henrik

[TCPlomp]

I haven't tried but you could use the PushOK SCC Dispatcher that works as a proxy and can invisible switch between SCC providers.

Ton

[arolin]

I have been struggling with how to effectivly manage a project with a lot of LabVIEW components in an SVN repository for a couple of years now.

This week I have a new project that needs to come up to speed on LabVIEW and Source Code Control.

I just stumbled across some documents about the svn:needs-lock porperty which will allow me to change the comit model, and which will make the files read only which works with the LabVIEW don't save uncecessary changes options. I think you also need to tell it not to check out everything's mother in the repositor each time you make a tiny change.

I think a key factor is the integration with SCC api links. So far I have found PushOK and TamTam. I have tried PushOK in the past and did not have great luck. Mostly I got errors while handling most of my commands. So far TamTam seems more seemless.

For both PushOK and TamTam I have a very hard time configuring the SVN connection. I know my URL very well because I can connect to the server, but it usually asks me if I want to creat the repository at the specified location and then complains that this is not possible.

As I was saying though, no one likes to unlock a file by hand each time they want to save something they have edited. It is essential for ctrl-m to promt for a check out.

Per project SCC connection make a lot of sense, but I sure don't need them now, I just need acess to SVN to work reliably from the project shell.

my 2 cents, and any advice would be appreciated.
Amaury

[Elijah_K]

There is a wiki document available on the community site that may be of help to those of you on this thread.  It's all about group development and talks a lot about application management in the Project Explorer using integrated source code control.  You can find it at this link: http://decibel.ni.com/content/docs/DOC-1681.  You should also be aware that it is a part of a larger series of content on software engineering best practices, which you can find here: ni.com/labview/power.

Since it is a wiki, I encourage you to contribute any insights or information you feel would be valuable for other users!

[TCPlomp]

Nice wiki-document.

I have made some months back a feature request to exclude user.lib from the hyarchy when using SCC options (just like vi.lib and instr.lib).
Is there a status update on this?

Ton