Anyone maintain multiple LV versions of VI's with SCC?

[8bitbanger]

Hi Folks,

This has to be one of the largest things I struggle with on a daily basis, that makes me wanting to move away from NI. I have now-legacy hardware that I must continue to support, but it was dropped from 8.6 and higher. So I'm running 8.5.1 and 2009. I prefer to keep abreast with the latest LabVIEW version, but NI is NOT making this an easy thing to do.

I have slowly established a good sized code re-use 'library', and am working to integrate MS VSS into the mix.

How have you handled legacy hardware, multiple versions, and source code control? Do you establish different versions (LV I mean) of the same file within the repository? Or does this simply confuse the mix?

Again this is a *constant* battle. If I devel a project in 2009, make the mistake of a mass compile, everything is broken for my older projects and it takes 1/2day to sort out dependancies.

<grumble>

Jamie

[smercurio_fc]

---

@8bitbanger wrote:

Hi Folks,

I have slowly established a good sized code re-use 'library', and am working to integrate MS VSS into the mix.

---

That's probably your first mistake. If you do a search in this forum on SCC you will see that nobody has recommended VSS. Most folks here use SVN, with some sprinkling of other SCC programs. A decent SCC program will allow you to do this so that if you "screw up" you can go back to a previous revision. Have you read this article: http://zone.ni.com/devzone/cda/tut/p/id/6524 ?

The ultimate solution, though, would be to have a separate virtual machine for the one code base. That would guarantee you don't save the 8.5 code in 2009 version.

[8bitbanger]

I did indeed read some of the articles here in NI Zone in regards to SCC, and was given the impression that VSS was an acceptable solution.

In regards to running the virtual machine, I have heard that suggestion from an NI Engineer, and honestly, think it's complete hogwash that I should have to run VMware or the likes for the *development* environment. I'm sorry, but I just don't accept that as a 'solution'.

Thanks for the reply, and sorry for the rant, but I'm really getting sick of dealing with this BS that does nothing but get in the way of development time.

Jamie

[smercurio_fc]

---

@8bitbanger wrote:

I did indeed read some of the articles here in NI Zone in regards to SCC, and was given the impression that VSS was an acceptable solution.

---

It is compatible as far as NI is concerned. However, I, as well as many others, have found that VSS is a piece of junk. I've used it and think that SVN is superior in more ways than I have fingers and toes. Nobody is telling you not to use VSS - I am just offering my opinion, which is based on experience.

---

In regards to running the virtual machine, I have heard that suggestion from an NI Engineer, and honestly, think it's complete hogwash that I should have to run VMware or the likes for the *development* environment. I'm sorry, but I just don't accept that as a 'solution'.

Thanks for the reply, and sorry for the rant, but I'm really getting sick of dealing with this BS that does nothing but get in the way of development time.

---

Well, again, nobody is telling you that you HAVE to use a virtual machine. I'm pointing out that as an ultimate solution. I don't think it's strictly necessary to go that far, but it's pretty much guaranteed to keep things separate. I think you can get by with a robust source code control system, as they are designed to handle this kind of situation.

But that's just my opinion, whether you consider it BS or not.

[Britoa]

We keep our 8.5.1 and 8.2 code in separate parts of the source tree.  So there are two copies floating around, but it makes life so much easier to maintain.  If we have a dumb moment, more than likely, it's not saved in the source tree, and we just revert, otherwise, we go back a few revisions to a working copy.  I myself have a second development machine just for 8.2, it makes me actively think about what I am opening where.  (this was before we jumped into source control)

[Spectre_Dave]

I have also maintained multiple duplicate versions of code in VSS. If you are working in a team environment only allow the more seasoned individuals to have access to the multiple versions of code.  The junior developers only get access to the version they are working on currently.  This helps to prevent cross contamination of the code.

[8bitbanger]

Thanks for all the replies;

smercurio_fc none of that griping was targeted at you, really. Sorry to be such a bear.

The primary reason I turned towards VSS first was because our IT department presently supports it, so implimentation would be less of a hasstle. Our team is very small (two people), so the SCC is really a vehicle for organization, not so much for file checkout/locking purposes.

---

@Britoa wrote:

...We keep our 8.5.1 and 8.2 code in separate parts of the source tree....

---

Are you referring to a directory hierarchy or in terms of the SCC tree? Is there any preference between keeping multiple versions within a branch of the tree (in other words, LV8.2 and LV8.5.1 versions of a VI both within a 'file operations' branch), vs multiple 'trees'? Does this make sense?

Also are you running off a centralized server, or local instance of VSS?

Once VSS is up and running, I'll certainly give SVN an equal evaluation. However I don't believe our IT department will be so willing to serve Subversion. 😞 

[Britoa]

I mean different directories, we have an 8.2 folder and an 8.5.1 folder.  This is on an SVN server run by our IT guy

[Dennis_Knutson]

From what I have been told, VSS development has stopped and will become obsolete. That's a pretty good reason to avoid it. Don't remember what the replacement is called.

[8bitbanger]

---

@Dennis Knutson wrote:

From what I have been told, VSS development has stopped and will become obsolete. That's a pretty good reason to avoid it. Don't remember what the replacement is called.

---

This seems to be the case, as they are moving towards their 'Team Foundation'. http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=sourcesafe&Filter=FilterNO