Getting Started with a Source Code Control

[F._Schubert]

Hi,

read several blogs argueing, that Source Code Control (SCC) is benefical to even one-developer projects. So I want to give it a try as soon as time permits.
So several questions to other users:

1. Which are 'ready-to-use' SCC solutions for LV 7.1 FDS, Win XP?
2. Can the Server side also be based on a Linux Server?
3. How long does it take to (a) learn the tool and (b) migrate an active project to SCC (400-1000 VIs).
4. Is it advisable to migrate an active project to SCC?

Felix

[smercurio_fc]

To provide some answers to your questions:

1) "Officially" LabVIEW 7.1 supported Perforce and Microsoft Visual Source Safe. People have gotten it to work with TortoiseCVS. LabVIEW 8 has a much larger "official" list.
2) Not absolutely certain about this one, but I believe yes, as long as LabVIEW recognizes the client you're using to access the repository on the server (CVS lingo).
3) How long depends completely on the tool, but they're quite "user-firendly" nowadays. Usually it's the server side that's annoying. Migration time is hard to gauge. How long does it take to add files to a source code repository?
4) Any project can stand to benefit from source code control at any time, regardless of its state of activity.

[Gabi1]

sorry to steal the thread but i got interrested:

i would like to see such a tool embedded in LV. i could then see all changes history on a single vi, without multiple copies. true the vi size would be much larger, but this would be only the repository copy, and not the working one. what do you think?

[tbob]

We are using Microsoft (yuck) VSS.  The administration was not that hard to pick up.  MS has complete instructions on how to start and maintain the VSS system on their website.  It was not that easy to find, but it does contain a lot of information which I printed out into a book.  Labview works nicely with it.  You have to configure Labview, which is easy.  Then if you start to change a vi, LV will prompt you to check it out of VSS.  You can do so, or decline and continue with your changes.  I like it because it prevents me from inadvertantly changing a vi without checking it out first.  That makes it easier to track all changes.  I can't believe I'm pushing software from MS!!!!

[tst]

I set up SVN for us and it works fine, but setting up the server side and learning how to use everything takes time. The server should also be runnable on Linux, but I use a Windows server. Using the client side (at least on Windows) is easy - TSVN integrates into the Windows shell, so you can use it with any kind of file. Setting up diffing for LV was a bit of work, because I wasn't happy with the existing version of LVDiff, but you don't necessarily have to change it.

Using it is very easy as long as your users don't make a mess of it - if they don't update and commit properly and if they manually move files around, SVN will NOT like it and you will have to do cleaning up. So far, the main advantage I've found is that it allows very easy synching of code between different computers - you just commit in one PC and then update in the other. It only takes two mouse clicks.

It's also useful to have a revision history which is not limited to a single file and when I commit, I don't usually commit each file, but a bunch of changes together.

---

@Gabi1 wrote:

i would like to see such a tool embedded in LV. i could then see all changes history on a single vi, without multiple copies. true the vi size would be much larger, but this would be only the repository copy, and not the working one. what do you think?

---

LV used to have its own SCC plugin, but it was ditched since ultimately, there's no real point to it - that's what the SCC system is supposed to do. If you only want written changes, you can use the VI revision history, but NI was considering removing even that.

[Gabi1]

i am actually using quite intensively the revision history. but what i want is an automatic history save in the sense of "ctrl-z", with the listed changes. then i can always make newer versions and come back if needed, without the hassle of multiple versions and multiples files. of course this would work on the repository duplicate of the vi. in a sense that would be an addition/option of LV on the SCC (i think).

[Neil.Pate]

I am using TortoiseSVN (windows clients) with a linux server.

Actually I am cheating a bit, and the server is just a linux box with directories shared out to the windows hosts (using samba on the linux box), which are then mapped in windows as drives.

The SVN help cautions against doing this, but it seems to work fine in my single developer environment.

[F._Schubert]

Thanx for all your replies.

Seems my problem now is to upgrade from a FDS to a PDS...

Felix

[tst]

You don't need PDS with SVN, since the interaction with it can be done through the Windows shell.

You will need it, however, if you will want to do diffing on older versions (which you probably will, at some point).