Subversion is one of the most popular SCC systems in use yet currently LabVIEW can only integrate with the help of rather flakey 3rd party plugins. It would be so much easier if LabVIEW included native SubVersion support, allowing full integration with the LabVIEW Project etc.
SVN does support locking, it just isn't the defualt. If you add the SVN property 'svn:need-lock' to all your LV files, SVN will set those files to read-only on your disk. Getting a lock for that file will set the file to read-write. You'll also need to set the LV option to treat read-only files as locked.
SVN does support locks. We use them all the time. What is doesn't do is require locking by default. If you add the SVN property 'svn:needs-lock' to all your LV files, SVN will set files to read-only unless they are locked. If you set the LV option to treat read-only files as locked, you won't have the problem with multiple developers (unless they intentionally set files to read-write instead of getting a lock) See http://svnbook.red-bean.com/en/1.5/svn.advanced.locking.html for more info.
I'm trying out the JKI toolkit as we speak, but without the R'CLK functionality in the Project Explorer tree, I think I'm not going to wind up using it.
I don't think that NI necessarily needs to write a Subversion client (in fact, I don't think that is the best use of NI's resources when there are good clients available) but I do think that LabVIEW's integrated version control should support a suitable Subversion client that has a suitable interface and supports required functionalities. Currently LabVIEW's source code control integration for Subversion only supports Pusk Ok's client, which does not have sufficient features (does not even claim to support file delete or rename) and is, well, horrific software on any account--or at least it was when I tried it a while back. JKI's offering is an add-in at a cost (currently $99 per developer) and does support operations like delete and rename but only for VIs and controls, and so in my opinion is not sufficient either. We currently opt to use TortoiseSVN directly but this means we must perform certain operations such as renaming twice--once in LabVIEW and once through TortoiseSVN. It's workable--and better than the alternatives, I think--but we would certainly prefer to use integrated version control if there were a full-featured tool that worked well available to us (and I think such integrated version control is essential for any development tool that one will use in any sort of serious software engineering development environment).
One possible tool NI could look into is CollabNet's Subversion client. Another tool we use interfaces to this client (which is free to us) and it works quite well.
Same problem here. We also have to do all the renaming, remove, etc... operations twice. It would be so nice if the JKI-Tool or any other Tool would support all kind of LV-files and renaming, removing of directories.