What Source Code Control Are You Using?

[Vinny_Burzi]

We are using Pefroce for our SCC provider, and are very happy with it and the LabVIEW integration for the most part.  One area that I feel could use improvement is renaming files that are under source code control.  I have read the document Source Code Control and Group Development Practices in LabVIEW for Advanced Configuration Management Tasks and will try out the suggested Process for Renaming Existing LabVIEW Files in Source Code Control.  However, I would like to see an atomic rename operation that would rename the file in SCC and relink the file in LabVIEW.

Vinny

[Elijah_K]

Thank you everyone for posting your thoughts and insights.  By all means, keep them coming!

For those of you using Subversion, I want to assure you that we are listening and we are working on improving the experience of using SVN with LabVIEW.  I can't promise when or how you'll see changes, but I'll definitely keep everyone informed.  In the meantime, continue to share your feedback and thoughts as they help guide us in our efforts.

Cheers,

Eli

[EdDickens]

We recently transitioned from VSS to Subversion with TortoiseSVN.

No comparison really. Subversion just works and is so much easier to work with than VSS. wish we did it a long time ago.

[npoling]

We use Perforce for our SCC of all our code, not just LabVIEW.

[Jim_Kring]

I mentioned in my last reply that JKI uses TortoiseSVN.  Well, we've just announced a new product called the JKI TortoiseSVN Tool for LabVIEW, which allows you to use TortoiseSVN from directly within your LabVIEW Projects and VIs.

[LeifS]

Back in the days we used LabVIEW with VSS because it was used for our VisualBasic projects. This barely worked and gave us lots of headaces, mostly because of the way VSS works (i.e.no blame on LabVIEW).

For approx 6 years ago we converted to TortoiseSVN and haven't regret that decision once.We use TSVN directly and not via PushOK, because the VSS API that PushOK use limits the possibilities availiable.

A couple of our repositories are quite large but thats no problem for Subversion to handle. Sometimes we need to reach our repositories remotely over slow communication lines, and Subversion really does this very well, opposed to VSS.

We heavily use graphical diff (via LVDiff), and when LVMerge was released the concept of parallell development became not only practically possible, but also the default choise for us.

LVMerge is also a neccessity for working with branches (which we nowadays also use daily), regardless of which SCC model are being used (Locking / Parallell).

What I really want to see in the future is the separation of real sourcecode and the binary compiled code. Today recompiled VI's can be a real pain when used with unlocked SCC.

I my opinion this is the single most important change for future version of LabVIEW (in the area of SCC). Next to that I think that working on LVDiff / LVMerge to make diffing and merging more integrated would be great.

The integration of TortoiseSVN isn't so important, since it works very well on its own, but since TSVN seems to be one of the most frequently used SCC with LabVIEW it could be clever to integrate all its functionality into LabVIEW anyway.

/Leif

[shew82]

We use TortoiseSVN as a client and VisualSVN for our severs so news that NI is working on improving SVN handling makes me very happy (we also tried PushOK but found that it was just not a good enough experience so ended up using just the TortoiseSVN/Explorer interface).

For those who are interested, VisualSVN is a Subversion server package that combines Subversion, Apache and a really nice management user interface that makes it really easy to manage repositories and even allows us to use our Active Directory accounts / groups to set permissions (ie "All Domain Users" can read repostiory x, and "Managers" and engineers "y" and "z" have write privaleges as well). Oh, and it's free as well: www.visualsvn.com/server.

Shaun

[LabCat]

For years my old group used LV adn TestStand with Perforce (without the SCC plugin, which seemed flakey at the time).

I now work with a new group that doesn't use SCC at all.  Given that they currently invest $0 in SCC, it's tough for me to sell them on an expensive commercial solution, so I have pushed Subversion.  I had hoped the AnkhSVN plugin would work with LV and TestStand, but this seems not to be the case.  The solution I'm pushing now is TortoiseSVN.  I'm not keen on the PushOK solution.

[BuddyHaun]

We use subversion and TortoiseSVN. LabVIEW integration would be a plus but improvements to LVmerge would be a much higher priority.

[MattViewX.007]

I use Perforce and am very happy with it.