LabVIEW
LabVIEW and SVN
Info: I am a single developer, working alone (so maybe my comments do not apply), and using tortoise SVN (mostly) happily.
In my experience its not a great idea to go for weeks without committing changes back into the repository. I always try and leave the project build in a "runnable" condition at the end of a day's work, and then commit that code. Doing this helps to build up a habit of committing regularly (and then you can leave a meaningful commit log message).
I would rather commit too often than not often enough. Hard drives are cheap, network access over 100base-T or gigE means the commits should take not more than a few minutes maximum (in reality its often only a few tens of seconds maximum).
SVN has its problems, but it has saved my bacon on a few occasions already. And it is difficult to argue with its performance/cost ratio
In my experience its not a great idea to go for weeks without committing changes back into the repository. I always try and leave the project build in a "runnable" condition at the end of a day's work, and then commit that code. Doing this helps to build up a habit of committing regularly (and then you can leave a meaningful commit log message).
I would rather commit too often than not often enough. Hard drives are cheap, network access over 100base-T or gigE means the commits should take not more than a few minutes maximum (in reality its often only a few tens of seconds maximum).
SVN has its problems, but it has saved my bacon on a few occasions already. And it is difficult to argue with its performance/cost ratio
I can't respond to all of those, since I'm far from being a Subversion expert, but I understand your frustration. I can comment on some of them, though.
My first clue: Two developers could "lock" the same VI and make changes.
Not sure about that one. I know that SVN supports the locking model, but it's not its default behavior. The default is check out\update (if you already checked out), then work, then commit and resolve differences if any exist. No locking is necessary. The developers are responsible to talking to each other to make sure they don't work on the same code.
You will probably say that the whole point of SCC is that developers let the SCC tool prevent others from editing files they are working on, but this method works for many teams. It's a bit more problematic for LabVIEW, where your changes can affect many files, which is why people use the techniques described in this thread.
- SVN indeed seemed to work OK when it was just me ... or maybe one more developer checking in, checking out, updating , etc. code into and out of the SVN repository. But the more developers that got involved, the more errors and headaches crept into the process.
- Although I had no idea what the problems others were having, I saw, on more than one occasion, IT looking over a developer's shoulder who was unsuccessful trying to check in updated code. Sometimes the entire directory had to be deleted, the previous revision reinstated then checked out again, the new code redone and checked back in.
- I would get an error trying to check in some code. I would try the Tortoise/SVN - suggested solution. That would fix that problem but another would arrise. I would fix that. I could do this a half-dozen times then end up right back to the original error.
- It got so frustrating, and I had heard it so often for so long that if I had heard that insipid Tortoise/SVN error sound ONE MORE TIME I was going to start taking hostages.
For me, all of these sort of go together. My biggest problem is my coworkers. For me, Subversion plays nicely. For my boss, I often hear the very annoying sound coming from his office (we keep documents under SCC as well), at which point it's usually time to send the cavalry. I wouldn't be shocked if this would be even harder on us if we used VSS.
As with you, trying the suggest solutions usually doesn't help (I suspect that's because they are trying to handle other problems) and usually deleting the offending folder, updating to get it back and then reapplying the changes is required. Usually, this is done by simply moving the modified files and then moving them back, which is a simple enough solution.
I'm not sure, but I suspect most of these issues are caused by them moving and copying folders using the Windows shell. Since SVN keeps all the SCC info in hidden subdirectories, this causes it to go crazy when you try to commit.
You might think that this is bad design, but I happen to find this extremely useful, especially when working on large binary files like VIs. It means that all the comparisons can be done on the client's side, without having to send a lot of data through the network. This makes Subversion commits and updates much faster than VSS (at least for me).
Checking out a subdirectory occasionally created errors when attempting to check it back in. My biggest problem with this was that I could have a subdirectory checked out and locked for a week at a time, make numerous changes to numerous VI's in the subdirectory, then if just ONE vi had a problem none of the others could be checked in until the error on the one VI was corrected.
I would also advise against that, although I can understand how this could be a problem if you're working on a feature which takes a while to finalize. As for your problem, that is actually a feature, and one which I think is very good. In Subversion, commits are atomic - if one file fails, the entire commit fails. Since commits are supposed to represent points in time, this behavior is correct - everything has to go together.
I just had a good chat with a respected fellow LV guy and he claims his company uses SVN with about 30 developers - and he claims it works great for them. Yea, it's tricky at first but everyone eventually got the hang of it. I know a lot of highly respected and competent LV developers use it and think it's great. My previous problems were probably due to inadequate and faulty implementation, training and installation. We may move to SVN in my current company since our VSS license is old, has too few licenses and nobody (except me) seems to know how to use it. I'm prepared take this on myself (just to be able to say: "I kicked it's arse!") and take back a lot of the bad of what I said. We shall see. 
I'll update this thread if we continue with our progress ...
I'll update this thread if we continue with our progress ...
LabVIEW user groep 
Elijah K wrote:
Finally, I just had an avid LabVIEW user e-mail me with a 16 page document he put together on integrating SVN with the LabVIEW Project Explorer, which I've hastily posted here in order to respond to your question: Using SVN and PushOK with LabVIEW for SCC.*
*this wiki document on ni.com is open for editing and updating by the community. Please feel free to contribute.
This document is not available at this address, where can I find it
Thanks
Dany
