Source Control Software (SVN, Perforce, Git, etc)

[aputman]

I am just now getting around to installing SCC.  I installed the latest version of TSVN (1.12.1) but the VSI toolkit would not install from VIPM.  Error message says it's only compatible with TSVN version 1.8.x.  Looks like this toolkit is no longer being updated. Is there some secret to getting this installed on newer versions of TSVN?  I guess I could go back to a 1.8.x version of TSVN but that's not ideal.  I'm not sure yet what I would be losing if I downgrade to 1.8.x but since I am the only developer and I don't need a solution that is sophisticated, this might be the way to go.

The JKI SVN toolkit is no longer supported either.  It's my impression that SVN is being abandoned  for LabVIEW developing, in favor of Git or some other SCC tool.  Does anyone else get that vibe, especially since SVN toolkits are not supported?  

Does anyone have suggestions for a lone developer?  I'd like to know, in particular, what other lone developers are doing.  Perforce is free for up to 5 users but I haven't found any tutorials yet (haven't looked).  I will look into Git if that seems to be the new direction but the longer it takes me to type this message, the more I'm leaning towards downgrading TSVN.  I would still like to hear your opinions though.  Thanks.

[Gregory]

Hi aputman,

I use SVN with the Tortoise SVN Windows shell and have never felt the need to have it integrated into the LV project explorer. I make a couple of commits per day when I'm actively working on a project, so it would not save me much time, maybe 15 seconds each commit. I also recall trying to install the ViewPoint toolkit many years ago and it really slowed LabVIEW down. But as you've noticed these SCC and LV integration projects have not had maintenance lately. I think that's because there is not much demand for integration, regardless of which SCC you use.

To answer your other question, yes I think Git is gaining popularity among LabVIEW developers. Delacor has excellent guides for setting up SVN, Hg, or Git to use with LabVIEW. Some of the settings are on the LabVIEW side so it's worth a read / watch if you haven't yet.

[Bob_Schor]

I've been using Tortoise SVN (the "vanilla" version, where I close LabVIEW, open Windows Explorer, find my Project file, right-click and say "Commit" (that's in the evening -- in the morning, I find the Project file, right-click, and say "Update").  When I'm really busy updating and making changes, I may commit several times a day.  For the method I'm using (the "Do It Yourself" method), a key step is closing LabVIEW (oh, how many commits do I have where the comment is "Oops, forgot to Commit the Project file ...").

Being able to use TSVN has vastly improved the "safety" and speed of my coding (try remembering what you did and trying to "undo" it, as opposed to going back to "yesterday's version" ...).

Bob Schor

[RavensFan]

Bob,

Where do you place your repository?  Is it elsewhere on your PC?  Is it on a network server?

-Bill

[FlatCat]

Bob, 

Why do you have to quit LabVIEW to commit the project file? Can't you just Save All, or explicitly Save the project itself from the Project Window?

David

[Bob_Schor]

Two questions, two answers:

1. Where is (are) my SVN Repositories?  I currently am using two, and am considering "growing" a third.  Both are SVN Servers run and maintained "elsewhere".  One is a Visual SVN Server (of which I am an Admin) running on a Server somewhere within my University's "server farm".  When I wanted to "share" a repository with a colleague at another University and "access rules" kept her from being able to access our SVN Server, I opened a small account on a commercial SVN Hosting Service.  I am currently investigating maintaining my own "Server" using Visual SVN (uncertain of pros or cons).
2. Why do I advocate closing out of LabVIEW before doing a Commit?  This is an excellent question -- I could, indeed, do a "Save All" and then do my Commit safely.  However, maybe my "Absent-minded Professor" side is becoming more apparent -- I find that at least once or twice per month, I'll do a Commit, close all the open Windows on my desktop, and see the LabVIEW Project Explorer laughing at me, saying "You forgot to close me, again ...".  If LabVIEW isn't running, then the Project Explorer has been closed ...

Bob Schor

[ShockHouse]

Just chiming in with similar comments to the others. Right now the team I'm on uses SVN with that latest version of Tortoise (1.12...). We don't have any integration with LabVIEW and it honestly hasn't caused any issues. You just right click on the folder/files to check in, and it maybe adds like 5 seconds.

For our hosting we use RiouxSVN, which starts off free, and then depending on the size of your repository you can donate to upgrade.

[FlatCat]

I happen to have just started using TSVN this week, after a couple of years of thinking "I should really get source control". I am a lone coder, so I my repository is just a folder on my development computer. The the computer gets backed up to the cloud frequently. 

I also installed the ViewPoint Toolkit at first, but since it is a little finicky, and also because of some of the posts on this thread, I've now decided to uninstall it and just use TSVN straight up. 

So far, I really like it.  

[aputman]

Gregory,

Thanks for the blog/video link.  Git/Bitbucket looks to be really simple to setup and use.  It is a cloud based solution and requires PuTTy to transmit files but other than that, it's version control.  Fabiola does say in the article that once someone has tried Git, they will never want to go back to SVN.  So I think I'm leaning that way for now but I'm still open to other's comments.

[aputman]

---

@Bob_Schor wrote:

Being able to use TSVN has vastly improved the "safety" and speed of my coding (try remembering what you did and trying to "undo" it, as opposed to going back to "yesterday's version" ...).

---

This is what I'm most excited about.  I need to make a number of improvements to a medium sized project that we use internally but I have been hesitant to get started on them because I wasn't looking forward to making disk copies of my project (in the event I need to roll back a feature), keeping track of the changes, etc. 

It's also inevitable that as soon as I start making improvements, an immediate fix will need to be made that would require me to go back to the last known good release, make the fix, build it and send to the floor, and then apply the same fix to my version where I've started making improvements.  I think these types of development problems will be solved with proper usage of SCC.  I've just always bought into the idea that I'm a lone developer and don't need it.  Fabiola's video opened my eyes to the error in that thinking.