Ian,
I'm a Happy Subversive LabVIEW Programmer (pun definitely
intended). I'm also using Project with LabVIEW 8.5, and am using
Subversion (but NOT PushOK) to manage it. I will note that I initially
did install PushOK, but perhaps because I "don't get it" (and am new to
Version Control), it drove me crazy and I decided to "try without it"
(and am very pleased with the results).
Having now built a few projects under Subversion, here are What
Works For Me (your situation might differ). First, my LabVIEW
"projects" tend to actually be separate projects, so I tend to organize
them as separate "items" in Subversion. Say I have projects named
ProjOne, ProjTwo, and ProjThree. In my Subversion repository, I'll
have three "top-level" folders called ProjOne, ProjTwo, and ProjThree,
each of which has three folders called trunk, branches and tags. My
"working copy" (the folder on my PC where I do all of the LabVIEW
development) will essentially come from the contents of the
corresponding "trunk" folder.
Assuming I'm starting a new project (call it ProjFour), I would do the following:
1) Create a top-level folder for my project, to become the Working Copy. Call this folder ProjFour.
2) Create a Project (also called ProjFour) and save it inside this folder.
3) Create the VIs, libraries, etc. that you will need in your project,
organizing it as you find most effective. In my case, I'm at an early
enough stage that most of the VIs from my various projects are
completely independent of each other, hence I keep all of the project's
VIs and other files together inside the "project" folder (ProjFour, in
this example). I've found it convenient to create subfolders, both
"real" subfolders and "virtual" subfolders in Project, to keep the VIs
organized. Thus I have folders called Util, File, Tests, Templates,
Types (my term for controls, typedefs and enums), etc. Essentially the
only files in the ProjFour folder that is not in a subfolder will be
the ProjFour.lvproj and ProfFour.aliases files.
4) Create, in Subversion, a ProjFour folder, with trunk, branches, and
tags subfolders. Check in your initial Working Copy to the trunk.
You now have a Subversion repository of your project, as it exists
at "time of creation". Go ahead and modify, update, replace,
reorganize, etc. your code. At regular intervals (for me, this is
typically after I've done a day's work, especially if there's a chance
I'll want to "continue from home" to work on the same thing), commit
your changes. I strongly recommend that you turn on the option in
Subversion that requires that you post a Commit Log message (I think I
made my minimum be 40 characters), as this forms a sort of
"auto-documentation" of the changes.
Every time you start work, particularly if there are multiple
people working on the code (or you are working on it from multiple
PCs), update your working copy to be sure to get the latest changes.
As your code reaches "stability" (don't we wish!), you can "tag" it to
signify a stable release. So far, I haven't used branches very much,
and when I've tried, I've mostly confused myself!
I really like the "comfort" in having a known "backup" of the
code, complete with annotations, particularly for developing using
multiple machines (and sites, like Office, Lab, and Home), that
Subversion provides. Formerly, I would create folders called
ProjOne01Apr08, ProjOne03Apr08, ProjOne07Apr08, each of which would be
the current day's Working Copy, and carry it around on a USB stick.
However, there was no easy way to tell what changed from day to day,
nor a convenient way to "mark" a version as "relatively stable" to use
as a divergence point for trying a new development idea. Subversion
gives you all of this, particularly if you commit your changes at
"intelligent" breakpoints in the code development (and, of course,
document the version in the Commit log).
It is possible, even with only one person using the Repository,
for files to get "out of synch". Not to worry, Subversion has some
really loud and unusual alarm sounds that unmistakably alert you when
there is a problem or confusion! These were generally quite easy to
resolve, though you may need to utilize LabVIEW's Compare VI tool
(remember to rename at least one VI) to help you decide which is the
"right" version to keep.
Good luck. I hope you'll be as pleased with Subversion as I am.
Should you find any useful tricks (or should you decide that PushOK
really does offer great things that I've been missing), please reply.
Bob Schor
LabVIEW user groep 
