Source Code Control

[i2dx]

Hi Folks,

I am currently using Perforce as *my" Source Code Control tool with LV 8.20, but I am not really happy with it. I have not the energy to set up a Linux Machine and get CVS (or clonses) running, so the only alternative seems to bee Visual Source Safe 2005, correct?

Has anyone out there experience with Visual Source Safe 2005 and LabVIEW? I called Microsoft, but there is no trial software availiable, and I am not willing to spend 600 bucks for a "try". Or even better, has anyone a tip, where I can get a Visual Source Safe 2005 trial?

any comments are really apreciated!

thank you,

CB

[Ton Plomp]

Has anyone out there experience with Visual Source Safe 2005 and LabVIEW? I called Microsoft, but there is no trial software availiable, and I am not willing to spend 600 bucks for a "try". Or even better, has anyone a tip, where I can get a Visual Source Safe 2005 trial?

I use VSS 2005 with LV, but have some issues with them:

• when you loose you netwerk connection the SCC is not available resulting in a lock down of LV
  
• The level of control inside LV is limited (check in/check out)
  
• Sometimes the working folder deep down is wrong and you have broken links inside VI's (that might be a problem that is personal related)
  

I don't know where to get a trial version..

Ton

[Falevoz Y.]

I use VSS 2005 with LV, but have some issues with them:

• when you loose you netwerk connection the SCC is not available resulting in a lock down of LV
  
• The level of control inside LV is limited (check in/check out)
  
• Sometimes the working folder deep down is wrong and you have broken links inside VI's (that might be a problem that is personal related)
  

I don't know where to get a trial version..

Ton

Hi!

SVN seems to be aviable for windows serveur.

http://subversion.tigris.org/project_packages.html

Use the tortoiseSVN client... It's integreted to the windows explorer and very easy to use...

http://tortoisesvn.tigris.org/

Yann

[Mike Ashe]

... but have some issues with them:

• when you loose you netwerk connection the SCC is not available resulting in a lock down of LV
  
• The level of control inside LV is limited (check in/check out)
  
• Sometimes the working folder deep down is wrong and you have broken links inside VI's (that might be a problem that is personal related)
  

If you are going to use VSS, especially if you do it over the net, I would recommend Source OffSite by SourceGear

It protects the VSS database from corruption by the client, is MUCH faster than VSS's own net ttool(s) and IMHO has a better user interface.

SVN seems to be aviable for windows serveur.

Use the tortoiseSVN client... It's integreted to the windows explorer and very easy to use...

I'd rather see you try to use SVN and TortoiseSVN. Much cheaper, :thumbup: free online doc's book , several of the better LV programmers in the country are using it.

[Michael Aivaliotis]

I am currently using Perforce as *my" Source Code Control tool with LV 8.20, but I am not really happy with it.

Why?

[i2dx]

Why?

mainly because I have the feeling, that I don't have this tool *under my control* and I have difficulties in understanding the documentation and therefore, how the software works.

what the heck is clobber ???

O.k. I found out, that perforce will not overwrite existing files if I have not checked this option, but what does that mean? Is it really that, what I want to have? What happens to my files? I introduced Source Code Control, because these files are *somewhat important*, and I'd like to be sure that my source code control will not mess up something ?

e.g. checking out files. I check out files in LV, but they are not realy checked out. OK, in the Project Explorer they get the "checked out" icon, but if you edit them, LV informs you, that this file has to be checekd out. why? I don't wanna have a pending changelist somewhere, I just want the files to be checked out or checked in. Is there a way to force perforce to write the files immediately?

e.g. adding files. I just added a new project and wanted to get the last revision on my second machine. The files did not exist in the depot. I first had to open P4C, send the pending changes to the depot. check them in, check them out and then I could retrieve the files. strange. I added them in LV with "add to scc", why are the files not in the depot?

all in all it feels like sitting on a bike with a twisted wheel, I can hold in a way the direction, but it's not precise ...

[gmart]

mainly because I have the feeling, that I don't have this tool *under my control* and I have difficulties in understanding the documentation and therefore, how the software works.

It is true that Perforce's semantics take some getting used to. Why do they have to say "open for edit" when the rest of the world says "check out"? One good reason is that their semantic match how their software works. Perforce uses changelists so in reality when "check out" a file, you are really opening it for edit in a changelist.

what the heck is clobber ???

O.k. I found out, that perforce will not overwrite existing files if I have not checked this option, but what does that mean? Is it really that, what I want to have? What happens to my files? I introduced Source Code Control, because these files are *somewhat important*, and I'd like to be sure that my source code control will not mess up something ?

Regarding the "clobber" concept. From their documentation:

"Specifies whether p4 sync overwrites writable but unopened workspace files. (By default, Perforce does not overwrite unopened files if they arewritable.)"

The reason for this is because most files will be read-only if under source control, so if a file is writeable, Perforce doesn't want to overwrite it since it didn't explicitly change the read-only flag.

e.g. checking out files. I check out files in LV, but they are not realy checked out. OK, in the Project Explorer they get the "checked out" icon, but if you edit them, LV informs you, that this file has to be checekd out. why? I don't wanna have a pending changelist somewhere, I just want the files to be checked out or checked in. Is there a way to force perforce to write the files immediately?

What do you mean about files not being "really" checked out when done through LabVIEW? Once a file fis checked out, it shouldn't you to check out on edit. There is no way to get around changelists in Perforce as mentioned above so anytime you check out a file it will be on a changelist.

e.g. adding files. I just added a new project and wanted to get the last revision on my second machine. The files did not exist in the depot. I first had to open P4C, send the pending changes to the depot. check them in, check them out and then I could retrieve the files. strange. I added them in LV with "add to scc", why are the files not in the depot?

The "Add" concept in Perforce can be tricky if you're used to immediate add operations like in SourceSafe. Again. you are opening a file for add so the file gets placed on a changelist. It is not really added until you submit (check in) the file. Because of the generic interface in LabVIEW, adding a file to Perforce gets reported as the file being checked out. While it may look odd, it makes sense from a functional point of view.

all in all it feels like sitting on a bike with a twisted wheel, I can hold in a way the direction, but it's not precise ...

I would recommend sticking with Perforce a little while longer. It is pretty powerful and I think once you get used to the semantics of the software, you'll like it.

[i2dx]

gmart, thank you for this detailed response!

OK: back to the roots: I'll have to explain a little bit more:

You guessed right, yes I am used to Visal Source Safe (6.0). I used that when I was an employee. In 2004 I became an independent contractor / freelancer, and I was working alone: One Project, one folder on disk, one copy and an automated daily backup on my server. That worked pretty good for me, if I messed something up I had my backups and I could go back in history, if I needed to. Now I've come to the point, that I need a Source Code Control, and since I know, that NI preferes Perforce, it was my first choice.

The reason for this is because most files will be read-only if under source control, so if a file is writeable, Perforce doesn't want to overwrite it since it didn't explicitly change the read-only flag.

Hey, this is an explanation, I can understand. thanks

What do you mean about files not being "really" checked out when done through LabVIEW? Once a file fis checked out, it shouldn't you to check out on edit. There is no way to get around changelists in Perforce as mentioned above so anytime you check out a file it will be on a changelist.

yes, that was really strange. I checked the whole project out and started editing. When I was editing one file (that happened not with *all* files!) I got a dialog box, which informed me, that LV is now going to check out this file, because I am trying to edit this file. That was an automatic dialog, without buttons, which appeared and went of after a few seconds. I guess that had something to do with the chagelist concept?

It is not really added until you submit (check in) the file.

AH! got it. That's why there is the "keep files checked out" checkbox, right?

I would recommend sticking with Perforce a little while longer. It is pretty powerful and I think once you get used to the semantics of the software, you'll like it.

I'll keep on trying! again, thanks a lot!

[gmart]

The standard disclaimer is that NI doesn't officially "prefer" any specific provider. NI just happens to use it internally so we are more familiar with it. It just happens to be a good source control package (though the Subversion fanatics would probably disagree .

Regarding the prompt on edit, the feature in LabVIEW to do this is a dialog WITH buttons where you have to explicitly agree to check the file out. It might have been a Perforce specific dialog. There are two implementations for Peforce - Command Line and SCM. Command Line was written in LabVIEW and interfaces with Perforce. SCM is Perforce's implementation that LabVIEW calls.

Not to confuse you even more but the "Keep files checked out" box if for SCC providers that do an immediate add (such as SourceSafe). For Perforce during an add, because files are added to a changelist, the file is essentially "checked out" still so the option doesn't do anything. During a submit, the checkbox will reopen the file after you submit it.

[Mike Ashe]

(Perforce) just happens to be a good source control package (though the Subversion fanatics would probably disagree .

We're not fanatical, we're just enthusiastic

On another SCC note, gmart, can you comment on SCC with VIs inside of LLB's?

Thanks.

[Jacemdom]

We're not fanatical, we're just enthusiastic

On another SCC note, gmart, can you comment on SCC with VIs inside of LLB's?

Thanks.

I believe the LLB will be seen as one file...you will lose the possibility to submit changes to only one VI...you will always have to check out the entire LLB and submit the entire LLB...

I advise to use LLBs just as a quick code package to share code...i don't believe ther is a need to develop using LLBs anymore...even for plugin architetctures, i would suggest to use LLBs just for the deployment of the plugin and not in the source files...

[Mike Ashe]

I believe the LLB will be seen as one file...you will lose the possibility to submit changes to only one VI...you will always have to check out the entire LLB and submit the entire LLB...

I should have been more explicit, but I figured gmart would understand. I already knew about your point above, that current methods only allow single files. What I am asking is if NI is working on letting us do SCC with individual VIs inside LLB's. I see no reason why it should not be possible. Unfortunately almost all of the source code packages today assume that you are working with a text based language.

I advise to use LLBs just as a quick code package to share code...i don't believe ther is a need to develop using LLBs anymore...even for plugin architetctures, i would suggest to use LLBs just for the deployment of the plugin and not in the source files...

I respect your opinion, and a lot of people agree with you, but, I disagree. I've been programming almost fulltime in this language for a lot of years and I think LLBs are a good thing. You commonly see well written text based code that has multiple functions in one text file.

A long time ago there were a lot of problems with corruption of LLBs, it was a pain. Then people started using SCC packages with LabVIEW and everyone said to move to directories and single VIs since the SCC tools couldn't handle it any other way. To me that is a fault of SCC, not LabVIEW LLBs. Professional LabVIEW should have it's own SCC that handles LLBs.

Look in the \example or \project or \vi.lib or ... (you get the idea) directories and note how much of the code that ships in LabVIEW is in LLBs. If LLBs were so bad why are they not already split out into subdirectories? LLBs are convenient, compact, and I personally cannot remember the last time I had an LLB corruption problem.

Just, my opinion, YMMV

PS: If Windows Explorer can be given an extension that lets it look inside LLB's why not an SCC?

[crelf]

I respect your opinion, and a lot of people agree with you...

Add me to that list. As far as I remember, LLBs were a great way to save VIs with filenames longer than the old 8.2 FAT16 limitation. Sure, they now also offer some compression too, but I think that there's not real point to using them anymore. If you want to group files together, then use something more accepted: put 'em in a zip. Hey - now there's an idea: LabVIEW being able to open VIs in zip files!

[gmart]

I feel like we need a support group for LLBs and should all start out saying, "Hello my name is <blank> and I use LLBs" Rather than get into a philosophical argument regarding LLBs, I'll try to answer Mike's questions.

A long time ago there were a lot of problems with corruption of LLBs, it was a pain. Then people started using SCC packages with LabVIEW and everyone said to move to directories and single VIs since the SCC tools couldn't handle it any other way. To me that is a fault of SCC, not LabVIEW LLBs. Professional LabVIEW should have it's own SCC that handles LLBs.

As I see it, SCC packages are designed to work with files as they exist on disk. Taking LabVIEW files out of the picture, how do SCC packages handle files inside of zip files? Does it treat the zip file as one file or can it translate the zip file as a directory hierarchy and control it that way? I have not run into settings in the SCC packages I've seen that handle zip files in a way where you can control the contents. I'm not saying there aren't but I haven't run into them. So performing SCC operations on the contents of LLBs is analogous. Regarding LabVIEW having its own SCC, this was the case in pre LabVIEW 8.x. NI moved away from that model since NI is not in the business of developing source control systems. There are many packages that do SCC well and it made more sense to allow integration within LabVIEW for these packages rather than invest R&D resources in developing and maintaining this type of tool.

PS: If Windows Explorer can be given an extension that lets it look inside LLB's why not an SCC?

Viewing into LLBs in Explorer is done via a shell extension. While this might allow SCC providers to view LLB files on disk as directories, I don't know how it would handle storing the files on the server. Plus this technology is Windows only so the same behavior would not be supported on non-Windows platforms.

[Mike Ashe]

I feel like we need a support group for LLBs and should all start out saying, "Hello my name is <blank> and I use LLBs"

Ouch

Don't get me wrong, I've used directories and single VIs on my last three projects, including at my current client's, I just think think they're still useful and they're LabVIEW, so I'm partial. Plus, I admit, I really like to add and add to the tools and capabilities and seldom like to lose something if I don't have to.

Rather than get into a philosophical argument regarding LLBs, I'll try to answer Mike's questions.

Thank you.

<snip>

Regarding LabVIEW having its own SCC, this was the case in pre LabVIEW 8.x. NI moved away from that model since NI is not in the business of developing source control systems.

Okay, I'll buy that, I just wondered if NI was tinkering with it again in a skunkworks room somewhere. A couple of people have told me that NI is working on a lot more tools to handle LabVIEW code than before.

Viewing into LLBs in Explorer is done via a shell extension. While this might allow SCC providers to view LLB files on disk as directories, I don't know how it would handle storing the files on the server. Plus this technology is Windows only so the same behavior would not be supported on non-Windows platforms.

Yeah, I figured it was an extension. I was wondering if an extension to the extension would allow file operations inside the LLB, perhaps using a LabVIEW DLL made of VIs from the LabVIEW Library Manager. Hmm, maybe I'll have to experiment in my free time.

[jpdrolet]

I don't want to get into a philosophical argument either but what you really want is for LLBs to look like directories, feel like directories and behave like directories regarding the OS and other applications... You want them to be no different than directories... In short you want them to be directories...

I am not aware of a SCC application that manipulates and controls files within compressed files (ZIP) (correct me if I am wrong). Shell extensions can be made to hook into Windows Explorer and peek into ZIP files and LLBs and display their content as it would belong the the file hierarchy. However, other applications do not use Explorer hooks to access files, they use the file system API where ZIP files and LLBs are simply plain files. It would be a LOT of trouble (for very little gain) to integrate a LLB as a subfile system in the file system.

NI distributes most of LabVIEW VIs in LLBs. That is what LLBs are useful for: distribution. I myself distribute my applications VIs packed in executables and LLBs but I develop them as VI files. I'm quite sure NI also develops its VIs as files and packed them in LLBs only when a version is ready for distribution (I'm curious how they handle Open/Create/Replace File.vi...)

So you are free to use LLBs but do not expect them to be directories or that further development will be made for LLBs to gain the advantages of using individual files and directories.

[gmart]

Ouch

Don't get me wrong, I've used directories and single VIs on my last three projects, including at my current client's, I just think think they're still useful and they're LabVIEW, so I'm partial. Plus, I admit, I really like to add and add to the tools and capabilities and seldom like to lose something if I don't have to.

Unlike some developers at NI, I like LLBs :thumbup:. My previous comment was self deprecating humor...but as they say, if you have to explain the joke, it wasn't funny