SVN Repository question with LV8

[jdebuhr]

Hey All,

I am working on setting up Version Control Software. I am going to use Subversion along with TortoiseSVN. I have a second PC to use to serve the files (using Apache) I also installed SVN and TortoiseSVN.

anyway I need to move my projects over to the server.

I was thinking of one repository for each project, but in some instances some of the Sub VIs are shared for better code reuse instead of having duplicates for each one.

Another thought would be to keep everything bundled as one repository and then create branches.. since some of the core stuff will be shared..

I am new to all the SVN Stuff so bear with me.. I also did a search on here but did not see anything that is similar to what I am asking.

[Guillaume Lessard]

You can do multiple repositories, importing a shared "utilities" repository as an "external". Unfortunately, I don't think there's an interface to do so in TortoiseSVN; I handle my externals by ssh-ing into a unix box and using the svn cli tool:

% svn propedit svn:externals <target directory>

The advantage of using externals rather than branching for shared VIs is that you can "freeze" them at a given version; on the other hand, it makes updating your working copy substantially slower.

Also, there's probably little reason to use multiple repositories; you can do:

<root>/Project1/trunk

<root>/Project1/branches

<root>/Project1/tags

<root>/Project2/trunk

<root>/Project2/branches

<root>/Project2/tags

<root>/Utilities/trunk

<root>/Utilities/branches

<root>/Utilities/tags

...all in the same repository. You can also use externals within the same repository in order to keep everything in sync (I do this for some simulation code I run in Igor.)

Hmm. I hope this doesn't raise more questions than it answers...

[bbean]

You can do multiple repositories, importing a shared "utilities" repository as an "external". Unfortunately, I don't think there's an interface to do so in TortoiseSVN; I handle my externals by ssh-ing into a unix box and using the svn cli tool:

% svn propedit svn:externals <target directory>

FYI. You can handle externals in TortoiseSVN by right clicking on the directory, selecting properties, and then the Subversion Tab

[James N]

I'm new to the Subversion world too. About a month ago I setup a server in our lab for our department's SCC needs.

I was advised to do the one-big-repository method with all my LabVIEW code (or in general, any mass of files that are related). That way it would be easier to reorganize the directory structure in the repository if necessary. A lot of advice I'm taking of faith.. figuring I'll understand the benefit down the road. I going to create another repo for each dept. member just for misc. files not related to any LabVIEW projects.

Yeah, migrating existing code into the repository is another challenge. I'm almost wanting to dictate that anything which goes into the repository must be cleaned up and rewritten to be more "reuseable". I really want to use this as a catalyst for new and better coding. I'm reluctant to populate the repository with the mess we've been working with before.

Another tip, in LabVIEW edit the Options and check the "Tread read-only VIs as locked" and "Do not save automatic changes".

Then before each commit and after each update, make all of your files READ-ONLY. As you know, often LabVIEW will indicate a file has changed when you really didn't change anything. Say some path to a DAQ VI has changed. You may not want to increment the revision number just because of this.

Then change the write status of only those VIs you are working on. Or you can do it when you save and the "Cannot save VI..." message appears.

Ctrl-M will "unlock" any read-only VIs allowing you to modify it. But the file on the disk is still read-only and thus protected.

Good luck,

James

[jdebuhr]

I'm new to the Subversion world too. About a month ago I setup a server in our lab for our department's SCC needs.

I was advised to do the one-big-repository method with all my LabVIEW code (or in general, any mass of files that are related). That way it would be easier to reorganize the directory structure in the repository if necessary. A lot of advice I'm taking of faith.. figuring I'll understand the benefit down the road. I going to create another repo for each dept. member just for misc. files not related to any LabVIEW projects.

Yeah, migrating existing code into the repository is another challenge. I'm almost wanting to dictate that anything which goes into the repository must be cleaned up and rewritten to be more "reuseable". I really want to use this as a catalyst for new and better coding. I'm reluctant to populate the repository with the mess we've been working with before.

Another tip, in LabVIEW edit the Options and check the "Tread read-only VIs as locked" and "Do not save automatic changes".

Then before each commit and after each update, make all of your files READ-ONLY. As you know, often LabVIEW will indicate a file has changed when you really didn't change anything. Say some path to a DAQ VI has changed. You may not want to increment the revision number just because of this.

Then change the write status of only those VIs you are working on. Or you can do it when you save and the "Cannot save VI..." message appears.

Ctrl-M will "unlock" any read-only VIs allowing you to modify it. But the file on the disk is still read-only and thus protected.

Good luck,

James

Considering I am new to Subversion (and UNIX Commands) it will take a bit to understand everything. As for the code reuse.. I am in the midst of rewriting most of my Code anyway, cleaning everything up, making things better for the end user and even the ability of reusing some vis for other things. I think I am goign to start out with everythign in one repository, currently I have 3 different test apps (with 2 more on the list to be redone) so a total of 5.. 4 of them share many components and the last one just shares a smaller amount. If I were the only one doing all of it it would not be too much of an issue, but I have a second guy who is learning LabVIEW and will be doing some of the coding as well.

Thanks for the info so far..

[gmart]

While there is much love for Tortoise SVN for managing Subversion projects, you can try an SVN plugin for Windows made by PushOk that lets you work with your repositories (doing basic check in/out operations) from within LabVIEW 8.x.

[LAVA 1.0 Content]

Related to the topic. Does anyone know if someone has written a subversion API for LabVIEW. Subversion has a C API which allows directly integrating your application to SVN repository. I'd like to use a LabVIEW application to directly communicate with SVN and I wonder if I have to write the LabVIEW version of the API myself...

[bbean]

While there is much love for Tortoise SVN for managing Subversion projects, you can try an SVN plugin for Windows made by PushOk that lets you work with your repositories (doing basic check in/out operations) from within LabVIEW 8.x.

Do you know how much a Pushok license costs? I don't want to have to fill out all that info on the website just to find out.

Brian

[jdebuhr]

Do you know how much a Pushok license costs? I don't want to have to fill out all that info on the website just to find out.

Brian

Yeah there is no info on there website for it.. I have to go through too much red tape here for that.. if ther was a free plug in that would be better, but I will slowly learn and adapt to using TortoiseSVN outside of LabVEIW

[James N]

Yeah there is no info on there website for it.. I have to go through too much red tape here for that.. if ther was a free plug in that would be better, but I will slowly learn and adapt to using TortoiseSVN outside of LabVEIW

Yeah, I agree. Don't try to tie TortoiseSVN or Subversion into the LV Source Control option. Once you get the hang of manipulating files (.vi, .doc, .xls, .whatever), you'll start to consider putting all kinds of stuff under "revision" control.

Somewhat unrelated topic, but I'm running Subversion and Apache on a Windows XP machine and am thinking of using the Windows Scheduler app to run a backup (hotcopy) routine each week, then dump that to a network drive which gets maintained by corporate IT.

Anyone thought of other good ways to keep your repositories backed up?

-James

[Jacemdom]

I never worked with Subversion. If you want to go with another software, you can use Perforce for free if you have no more than 2 users...

[Chris Davis]

Yeah, I agree. Don't try to tie TortoiseSVN or Subversion into the LV Source Control option. Once you get the hang of manipulating files (.vi, .doc, .xls, .whatever), you'll start to consider putting all kinds of stuff under "revision" control.

Somewhat unrelated topic, but I'm running Subversion and Apache on a Windows XP machine and am thinking of using the Windows Scheduler app to run a backup (hotcopy) routine each week, then dump that to a network drive which gets maintained by corporate IT.

Anyone thought of other good ways to keep your repositories backed up?

-James

I use the hotcopy technique to make a copy of the repository, scheduled with the windows scheduler I end up dumping it to a network drive which is mirrored every day to an external USB drive.

As a side note, has anyone done a repository restore from a hotcopy?

[gmart]

Yeah there is no info on there website for it.. I have to go through too much red tape here for that.. if ther was a free plug in that would be better, but I will slowly learn and adapt to using TortoiseSVN outside of LabVEIW

I checked with PushOk and they charge $24 per license for their SVN plug in (similar charge for CVS).

[jdebuhr]

I checked with PushOk and they charge $24 per license for their SVN plug in (similar charge for CVS).

That is not too bad.. Although like James N said, I might start using it for Other documents.

James N,

I though of doing the SAME thing you are.. I have a Windows 2K machine that has Apache loaded and is my repository. I will be installing a free back-up utility when i get back from my vacation ( I leave tomorrow) I have the link for the free-ware program at Home. My Bro-in-law uses it on his home pc and it looks very user friendly. I plan on installing that on my Win 2K machine and doing a back up to a network drive as well.

There will be 2 users for now so I could go to Perforce, BUT if I ever added more then it gets costly really quick. The nice thing about Subversion is I can install it and use it at home for other projects and such and it is free.

I have been doing some practice stuff with Tortoise and Subversion this week and don't mind having it separate from LV. We will see once I start..

[LAVA 1.0 Content]

Has anyone experience of SourceHaven SVN implementation. I've though of it as an alternative to open source SVN.

[bbean]

Also, there's probably little reason to use multiple repositories; you can do:

<root>/Project1/trunk

<root>/Project1/branches

<root>/Project1/tags

<root>/Project2/trunk

<root>/Project2/branches

<root>/Project2/tags

<root>/Utilities/trunk

<root>/Utilities/branches

<root>/Utilities/tags

...all in the same repository. You can also use externals within the same repository in order to keep everything in sync (I do this for some simulation code I run in Igor.)

Some questions about SVN and LabVIEW. How do ppl deal with multiple LabVIEW versions in SVN? or more specifically what subversion repository structure do ppl use for multiple LabVIEW versions?

Is it like this:

<root>/Project1/LabVIEW 7.1/trunk

<root>/Project1/LabVIEW 7.1/branches

<root>/Project1/LabVIEW 7.1/tags

<root>/Project1/LabVIEW 8.0/trunk

<root>/Project1/LabVIEW 8.0/branches

<root>/Project1/LabVIEW 8.0/tags

<root>/Project2/LabVIEW 7.1/trunk

<root>/Project2/LabVIEW 7.1/branches

<root>/Project2/LabVIEW 7.1/tags

<root>/Project2/LabVIEW 8.0/trunk

<root>/Project2/LabVIEW 8.0/branches

<root>/Project2/LabVIEW 8.0/tags

<root>/Utilities/LabVIEW 7.1/trunk

<root>/Utilities/LabVIEW 7.1/branches

<root>/Utilities/LabVIEW 7.1/tags

<root>/Utilities/LabVIEW 8.0/trunk

<root>/Utilities/LabVIEW 8.0/branches

<root>/Utilities/LabVIEW 8.0/tags

Or Like this:

<root>LabVIEW 7.1/Project1/trunk

<root>LabVIEW 7.1/Project1/branches

<root>LabVIEW 7.1/Project1/tags

<root>LabVIEW 7.1/Project2/trunk

<root>LabVIEW 7.1/Project2/branches

<root>LabVIEW 7.1/Project2/tags

<root>LabVIEW 7.1/Utilities/trunk

<root>LabVIEW 7.1/Utilities/branches

<root>LabVIEW 7.1/Utilities/tags

<root>LabVIEW 8.0/Project1/trunk

<root>LabVIEW 8.0/Project1/branches

<root>LabVIEW 8.0/Project1/tags

<root>LabVIEW 8.0/Project2/trunk

<root>LabVIEW 8.0/Project2/branches

<root>LabVIEW 8.0/Project2/tags

<root>LabVIEW 8.0/Utilities/trunk

<root>LabVIEW 8.0/Utilities/branches

<root>LabVIEW 8.0/Utilities/tags

Or neither :question:

Branch/Tag/Trunk directories

When you do a checkout to the local machine do you prefer to see the \branch, \tags, \trunk directories from the reository on the local machine?

Utilities

Do you checkout your "utilities" directly to the appropriate versions user.lib? Or do you use externals and checkout everything (project vis and utilities via externals) to a local project directory?

Sorry for all the questions, just trying to figure out what works best for people? :beer: