Andy Peters

QUOTE(i2dx @ Jan 11 2008, 03:09 AM) It is not necessary to set up a Linux server for your Subversion repository. If it's just you, working on your own projects, you don't even need a server; you can access the repository using the file:// semantics.Here at the office, I have the Subversion server running as a service on a WinXP box. It was a snap to set up. It doesn't require you to build Apache or any of that. Grab the latest binaries from here and following the instructions here. You access the repository using the svn:// semantics. I can access this repository from anywhere on the company network.At home, I have a Mac mini serving the repository using Apache. This was a bit tricky, as at the time, OS X did not ship with Apache2. However, Apple does have instructions on how to build Apache2 and Subversion, which worked and all is well. Now I am running Leopard, which includes Subversion and Apache2. I kept the custom-built copy of Apache2 (which included the mov_dav stuff required by svn) because it just works. The Apache daemon serving svn listens on a non-80 port. The repo is accessed using http:// semantics and I can get to the repo from anywhere on the internet.good luck,-aQUOTE(silmaril @ Jan 11 2008, 02:40 AM) SVN's algorithms seem to work on a directory basis mainly. If you add a new file to a directory, it will be sent to the server with your next commit (at least that's what I remember). Yes, that's true. Also, if others are working on the same project, or if you develop on more than one machine (as I do), make sure that you do an svn update before working, so that you always have the latest versions of all files. You REALLY want the latest versions because merging VIs is ... rather impossible!-a

QUOTE(torekp @ Oct 1 2007, 04:49 AM) I'm perhaps a little late replying, but here's what I think. I use Subversion, so my examples will be typical for svn repositories, but the ideas should be usable with any SCC system. Subversion does not have any way to tell you where a particular file is used. If you have subVIs that are shared among multiple projects, it makes sense to maintain those subVIs as separate projects. To that end, you should always use a tagged revision of that subVI project. Tags are considered immutable (although in Subversion this is by convention and not enforced), so always using a tag rather than the trunk guarantees that if someone (yourself?) changes the subVI, the version you use in your project will not change. In Subversion, to include a subVI in your project, you have to attach an svn:externals property, pointing to the subVI URL in the repository, to your project. Then when you do an svn checkout on your project, you get the subVI too, in its own subdirectory under your project directory. Now, if you need to change that subVI, which is maintained as its own project, here's what you do. First, completely exit LabView! Change the svn:externals property on your main project to use the subVI project's trunk instead of the tag. (Or change it to whatever revision was used to create that tag.) Then do an svn update, which will automagically replace the tagged version of your subVI with whatever's in the trunk. Now reopen the main project in LabView and it should be good. Now you can modify the subVI and your main project VI to fit your needs. When you're done, save everything, then close LabView to ensure all changes are actually saved. Then commit the subVI back to its trunk. Create a new tag for the subVI in its project. Back to your main project, change the svn:externals property to point to the new tag, do an svn update on your project and you'll get the new tag as part of your project. Open the main project in LabView to make sure all's well, then when you're happy, save the project, close LabView, then commit all of the changes for your main project, which includes committing the svn:externals change. Now you're good. I have a couple of large LabView projects structured this way. One uses seventeen separate subVI projects, all brought in using svn:external, and I've found that this method is the only way of preserving my sanity when re-using subVIs. I should note that this methodology isn't something that's useful only for LabView; I use it with VHDL sources for FPGAs and C sources for microcontrollers, too. One more thing: consider setting the svn:needs-lock property for all VIs. In each users's home directory you'll find a subdirectory called .subversion (or perhaps it's in C:\Documents and Settings\username\Application Data\Subversion, G-d I hate Windows), and in there will be a file called config. In that file is a section called [auto-props]. In that section, add the following lines: *.ctl = svn:needs-lock=* *.vi = svn:needs-lock=* Then when you initially svn import a project or svn add a new VI or control, the needs-lock propery will be set. When you check out a file with this property, it will be read-only, so to modify it you need to get a lock from the repository (simple svn lock Foo.vi). You can then modify it. Nobody else can modify the file while you have it locked. This is a Good Thing because LabView VIs are binary and merging is basically impossible. Once you make your changes, commit the file and unlock it so if others need to modify it, they can do so. Good luck, -a PS: if you're using Subversion on Windows, you really need http://tortoisesvn.tigris.org/' target="_blank">TortoiseSVN. Really.