New to Source Control and looking for easy... safe solution

[rharmon@sandia.gov]

So I spent much of the afternoon looking over postings here on Source Control Software and LabVIEW. I must say I came away discouraged.

I've been programming LabVIEW for over 20 years in a single one technician lab and never really needed any stinking source control. Well now that's not the case. But thought I'd just read some posts, determine what everyone else likes and be done!!!!! That didn't work out for me ether... Seems nobody really likes source control after all. Or at least there are issues with just about every option.

So here is my situation. I'm still the single labVIEW developer on a project. But the project requires a more structured source control environment. So I'm looking for source control that works flawlessly within LabVIEW and  is easy to use, I'm Using latest versions of LabVIEW.  

Since most of the posts I read today are from years back, I'm hoping things have really improved in the last couple years and you guys are happy as a lark with your source control environment.

If you could take a minute and tell me:

1. What type of source control software you are using?

2. You love it, or hate it?

3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else

4. Pro's and Con's of the source control you are using?

5. Just how often does your source control software screw up and cause you major pain?

Thank you in advance.

Bob Harmon

[crossrulz]

I used to use Tortoise SVN.  It was extremely simple to use as it was right from Windows Explorer.  Due to company requirements, I have moved over to GitHub (enterprise server) with SourceTree as the interface.

Both work well for me.  The only real problems when it comes to SCC and LabVIEW is when you have to merge.  If you avoid merging, you will rarely have issues.  Text languages also have issues when it comes to merging, it is just easier to manage text files than binary files.  I have yet to run into any other issues due to the SCC screwing up.

[hooovahh]

I'm also a fan of SVN.  For multideveloper work we use VisualSVN Server.  The free version does a great job, but the paid version has domain integration among other enterprise features.  I'm not sure what can be used to make a local repo.  Jim had an old blog post years ago that I can't seem to find.

The client side I just use the explorer integration that comes with Tortoise SVN.  There are LabVIEW toolkits that add quick drop, or tools menu, and project integration, but none of them worked with our work flow enough.  Here is the first package I found made by JKI that does some of this.  I know ViewPoint also had one.  Here is Nancy talking about some of its features.

Oh and there are two paradigms when it comes to SCC.  One is Lock/Commit, and the other is Merge.  A single developer shouldn't need to worry about it (unless you are on multiple computers).  But I configure SVN to be Lock/Commit.  This means only one developer at a time can be editing a file.  You can break the lock, but then you may have two version of the file and then need to figure out how to merge them.  Locking helps avoid that.  When a developer is working on a subset of code, and no one else should be touching it, this works just fine.  But at some point someone may need to lock the whole project to update some large part of the code, and that is when going around and being like "Hey Brian can you unlock this I need it" would happen.

[G-CODE]

1. Mercurial (with TortoiseHg), Subversion, Git (with Sourcetree)

2. I have no option but to love any or all of them because the alternative (no source control) would make my life a lot more difficult.

3. Yes and yes. It just depends on the project. I would prefer Git just so I was always using the one that everyone else in the world is using.

4. Subversion might be the simplest for you considering it sounds like you don't want to be using SCC in the first place. You mentioned wanting to use source control "within" LabVIEW and I think you can setup LabVIEW to work with SVN although I'm not doing it that way.  However, your computer will require constant connection with the central repository. Also, last time I tried to create a branch on Subversion, I vowed I would never try it again. It's difficult to give up the ability to easily create branches once you have it. Mercurial is a distributed version control system and seems easier to understand than Git, but that might be because I have used it more. Git has plenty of horror stories written about it when people are confused in the beginning. Eventually they learn it and the frustration subsides.

5. Once you learn what you're doing, almost never. The major pain is just in the beginning while you're learning. There is likely to be more initial pain with Git.

 

If you're a solo developer who is used to clicking the "Save All" button on the project every few minutes, transitioning to a more thoughtful workflow where you are mentally keeping track of what you have actually changed and only committing those files is going to suck - to put it bluntly. Yet another thing to think about! After all, who wants to think more? Imagine having to constantly interact with source control by constantly typing little notes about the work you just did. This might feel disruptive to your workflow. However, it's worth asking yourself why almost every experienced developer does this.

One customer I work with uses SVN and the way they use it is single commits of all their work they did that day with no commit notes. Is this helpful? Well I guess it's better than nothing. You could return to some prior state of the code although it would be difficult to figure out what state you were returning to. Consider this option if someone told you that source control is mandatory and you're just trying to check a box so you can say you're using some "stinking" source control.

If you're inclined to implement some best practices and you understand the software world interacts largely through GitHub and you would like to engage with that world, consider using Git. Keep in mind this will probably require more patience initially.

Whatever you choose, I don't think there is any way to completely avoid the cognitive discomfort that can arise from learning something new.

Eric Graham

[drjdpowell]

I assume you've seen my conversation: https://lavag.org/topic/21651-git-cant-be-this-terrible-what-am-i-doing-wrong/

 

[rharmon@sandia.gov]

3 hours ago, crossrulz said:

I used to use Tortoise SVN.  It was extremely simple to use as it was right from Windows Explorer.  Due to company requirements, I have moved over to GitHub (enterprise server) with SourceTree as the interface.

Both work well for me.  The only real problems when it comes to SCC and LabVIEW is when you have to merge.  If you avoid merging, you will rarely have issues.  Text languages also have issues when it comes to merging, it is just easier to manage text files than binary files.  I have yet to run into any other issues due to the SCC screwing up.

Ok, I'm about to show my ignorance of source control software, but I've noticed a bunch of comments complaining about issues with merging files. I'm not quite sure what merging a file means. Could you explain a little for me... thanks 

[ShaunR]

1.  Another SVN user.
2. Meh. The lesser of evils.
3. Not forced. Use it through choice.
4.  
   1. Pro's: Straight forward workflow. Works from windows context menu's (Tortoise SVN). Use it as a versioned restorable backup with no major hassle.
   2. Cons: Same as any other SCC with LabVIEW - merging - but workflow can help (use Branches. Partition work packages to reduce merging. Trunk gate-keeper).
5. Almost never but when it happens, it's always on the merge to trunk - Gatekeepers problem but can recover easily .

[rharmon@sandia.gov]

2 hours ago, hooovahh said:

I'm also a fan of SVN.  For multideveloper work we use VisualSVN Server.  The free version does a great job, but the paid version has domain integration among other enterprise features.  I'm not sure what can be used to make a local repo.  Jim had an old blog post years ago that I can't seem to find.

The client side I just use the explorer integration that comes with Tortoise SVN.  There are LabVIEW toolkits that add quick drop, or tools menu, and project integration, but none of them worked with our work flow enough.  Here is the first package I found made by JKI that does some of this.  I know ViewPoint also had one.  Here is Nancy talking about some of its features.

Oh and there are two paradigms when it comes to SCC.  One is Lock/Commit, and the other is Merge.  A single developer shouldn't need to worry about it (unless you are on multiple computers).  But I configure SVN to be Lock/Commit.  This means only one developer at a time can be editing a file.  You can break the lock, but then you may have two version of the file and then need to figure out how to merge them.  Locking helps avoid that.  When a developer is working on a subset of code, and no one else should be touching it, this works just fine.  But at some point someone may need to lock the whole project to update some large part of the code, and that is when going around and being like "Hey Brian can you unlock this I need it" would happen.

Great information packed post... Thank you

[rharmon@sandia.gov]

1 hour ago, drjdpowell said:

I assume you've seen my conversation: https://lavag.org/topic/21651-git-cant-be-this-terrible-what-am-i-doing-wrong/

 

Yes... Very frightening...  Buy toward the end it gets interesting... Maybe git is not so bad after all... Pretty sure it's not for me though... If one of my LabVIEW hero's is having trouble using it I better run away fast!!!

[crossrulz]

I regards to merging: https://en.wikipedia.org/wiki/Merge_(version_control)

In short, it is trying to reconcile the differences between two versions of a file.  This happens when you try to merge branches or if you are working in a team and more than 1 person tries to update the same file.  If working alone, just don't branch and you will never have to worry about merging.

[rharmon@sandia.gov]

2 hours ago, G-CODE said:

1. Mercurial (with TortoiseHg), Subversion, Git (with Sourcetree)

2. I have no option but to love any or all of them because the alternative (no source control) would make my life a lot more difficult.

3. Yes and yes. It just depends on the project. I would prefer Git just so I was always using the one that everyone else in the world is using.

4. Subversion might be the simplest for you considering it sounds like you don't want to be using SCC in the first place. You mentioned wanting to use source control "within" LabVIEW and I think you can setup LabVIEW to work with SVN although I'm not doing it that way.  However, your computer will require constant connection with the central repository. Also, last time I tried to create a branch on Subversion, I vowed I would never try it again. It's difficult to give up the ability to easily create branches once you have it. Mercurial is a distributed version control system and seems easier to understand than Git, but that might be because I have used it more. Git has plenty of horror stories written about it when people are confused in the beginning. Eventually they learn it and the frustration subsides.

5. Once you learn what you're doing, almost never. The major pain is just in the beginning while you're learning. There is likely to be more initial pain with Git.

 

If you're a solo developer who is used to clicking the "Save All" button on the project every few minutes, transitioning to a more thoughtful workflow where you are mentally keeping track of what you have actually changed and only committing those files is going to suck - to put it bluntly. Yet another thing to think about! After all, who wants to think more? Imagine having to constantly interact with source control by constantly typing little notes about the work you just did. This might feel disruptive to your workflow. However, it's worth asking yourself why almost every experienced developer does this.

One customer I work with uses SVN and the way they use it is single commits of all their work they did that day with no commit notes. Is this helpful? Well I guess it's better than nothing. You could return to some prior state of the code although it would be difficult to figure out what state you were returning to. Consider this option if someone told you that source control is mandatory and you're just trying to check a box so you can say you're using some "stinking" source control.

If you're inclined to implement some best practices and you understand the software world interacts largely through GitHub and you would like to engage with that world, consider using Git. Keep in mind this will probably require more patience initially.

Whatever you choose, I don't think there is any way to completely avoid the cognitive discomfort that can arise from learning something new.

Eric Graham

Great Information... I think reading through these posts I'm leaning toward Subversion or Mercurial... Probably Mercurial because from my conversation leading me toward source control touched on the need to branch my software to another project.

Next step... download the software on another computer (so I don't endanger my current projects) and give it a try.

I can't express how helpful these posts have been, It would have taken me days to try all different source control options available... 

Just read Crossrulz's reply and it states "just don't branch and you will never have to worry about merging"  Cool.... I guess I'll just have to cross that bridge when the time comes.

Thank you to everyone who replied... Now I'm going to go jump in the source control pool... It's cold outside I hope the water is warm...

[LogMAN]

1. Git
2. I don't hate it - the centralized nature of SVN simply didn't cut it for us.
3. No. It was my decision.
4. Pro - everything is available at all times, even without access to a central server. Con - It has too many features, which makes it hard to learn for novice users.
5. Only when I merge the unmergeable, so anything related to LabVIEW 😞

[LogMAN]

11 minutes ago, rharmon@sandia.gov said:

I think reading through these posts I'm leaning toward Subversion or Mercurial... Probably Mercurial because from my conversation leading me toward source control touched on the need to branch my software to another project.

If you are leaning towards Mercurial you should visit the Mercurial User Group: https://forums.ni.com/t5/Mercurial-User-Group/gh-p/5107

Edited February 25, 2021 by LogMAN
finding the right words is difficult sometimes...

[Jordan Kuehn]

I've used the aforementioned three and currently use Git+SourceTree. I've not had the problems others have had in that other thread with Git (yet) and in general it's straightforward to commit and branch. Any merging I have to do is a manual process, but when working on a branch I typically am altering a subset of files that I wind up just choosing over the previous ones. The integration with Jira is nice since I like the kanban boards and tracking issues with commits. We don't use this to its full potential, but I think that's also a good thing since it keeps productivity in focus rather than checking all the boxes in Jira. I mention this side of things because there are integrations with project management tools that vary by source control and IDE as well. If you have no need for those, SVN is probably a fine choice.

[G-CODE]

3 hours ago, rharmon@sandia.gov said:

Probably Mercurial because from my conversation leading me toward source control touched on the need to branch my software to another project.

Bob, I can't help but wonder if you might be mixing up terms here. If you're talking about using code from one project in another you might be thinking about Submodules (Git) or Subrepos (Mercurial).

Branching is typically done within the same project with the assumption that whatever work is done on the branch will get merged back into something considered the main or master. In LabVIEW, I suspect most of us try really hard not to modify the same file in multiple branches since merging VI's isn't as straightforward as merging text files. You might branch something to work on a feature that you're not ready to deploy, but you want to be careful not to also modify the same file in another branch because when it comes time to combine everything back into one (merge), the source code can't automatically reconcile a file that has changes in multiple branches. It leaves you in the position to decide which of the changes is the one to keep and which do you want to throw away or the worst case scenario - you think there might be unique changes in both of those edits that you need to figure out how to combine into one.

Eric

[G-CODE]

... to further elaborate on merging. Note that we have used that word with respect to branches in source control and also with respect to files. As I previously mentioned, if you're careful not to edit the same files in multiple branches, when it comes time to merge a branch, it doesn't require that you merge a file. Merging branches is easy as long as it doesn't also require you to merge files.

Edited February 25, 2021 by G-CODE

[Bryan]

Another SVN user here (With TortoiseSVN as standalone and also with an SVN server).  Was introduced to it years ago and have had no reason yet to move to any others.

I like it for its (relative) simplicity when compared with others.  

For LabVIEW, you can configure it to use the LVCompare and merge tools, (there are some blurbs online you can search for that tell you how to configure it). 

Drawbacks that I've found (in my current employment) is lack of organization in the repository (poor pre-planning).  They use one repository for EVERYTHING and it's gotten huge and didn't plan it for best use of the the branching/tagging functionality. 

Another one is searching this HUGE repository I have to work with.  I've found no easy way to search for files/folders/etc.  My workaround for this is to use the TortoiseSVN command line and dump an SVN list to a file - then search the file to get a relative location for what I'm looking for.

Edited February 26, 2021 by Bryan

[Francois Normandin]

1. Nowadays, Git 100%.

2. Love it. 

3. I forced it on my team, but even for my hobby coding, I use SCC. Those closer to retirement are having a hard time. For the younger folks fresh out of school, they'd be surprised if we didn't use Git. I wouldn't bet that all of them know what SVN means.

4. 

Pros:

• Large support community online. When stuck, I just spell it out in the search engine and I find a post on stackoverflow that solves my problem 
• It allows enforcement of a workflow that achieves modularity by design, through submodules.
• Easy to deploy a repo through a usb stick for offline instruments, and to merge offline changes back to server
• No one can reserve a file and accidentally prevent others to work

Cons: 

• No LV integration for visualizing changes

5. SCC never screws up, the developer or the client app does. The app client I use (SourceTree) has a tendency to show "detached heads" that magically disappear when I close the app and open it back again. Detached heads are very confusing and every time I see one, I'm extra careful not to lose any work done. They never occur in a simple repos: only when dealing with submodules. That's a buggy behavior of the app, not a failure of SCC itself.

[jacobson]

I currently use Git through SourceTree. I like it although I am very rarely working on a project with someone simultaneously so I'm the opposite of a power user and just need the core features to work well and be simple to use. Most projects will be on some GitHub or Bitbucket page so having straightforward integration with those two services was important to me.

I used to use GitHub for desktop as a client for a while but there was an update I didn't like so I moved to SourceTree. I've tried GitKraken as a client as well which I thought worked well. I have also used TortoiseSVN for a few projects for which I only wanted a local repo and it worked fine but I still prefer putting things on GitHub and using SourceTree if I am able.

The last time I had any big issues with my source control was when I was working on some FPGA code and I had to add a few more FPGA resources (FIFOs/DRAM) which caused changes in the .lvproj file that I figured would merge but didn't. It ended up being a lot less of an issues than I thought it would be and probably only cost me an hour or so.

On 2/25/2021 at 12:25 PM, rharmon@sandia.gov said:

Just read Crossrulz's reply and it states "just don't branch and you will never have to worry about merging"  Cool.... I guess I'll just have to cross that bridge when the time comes.

This isn't strictly true and it's not something I would worry about too much if you're working by yourself. I still find it useful to create a branch when I start working on a new feature and then merge that branch when it's done. As long as you don't touch the main branch once you create your feature branch (and if you're by yourself it's easy to make sure this doesn't happen) there won't be any conflicts and your code will auto merge.

[ASTDan]

1. What type of source control software you are using?

Tortoise SVN

2. You love it, or hate it?

LOVE it!  Been using it for many years

3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else

I use it because I want to.  The documentation I have with every version change is invaluable.  Also the ability to go back in time to a different version has been invaluable.

4. Pro's and Con's of the source control you are using?

Pro:

TortoiseSVN is very easy to use.  I have a repo for each project I store on my local machine.  Since I am a single developer I don't need a server.  I can commit to my repository at my office or at a customer site.  I haven't used TortoiseSVN in a multiple developer environment.  If I did I would use the Lock Modify Unlock method https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-basics-versioning.html.  I know a lot of people are moving toward a copy modify merge method using git.  I haven't tried it.   

Tortoise SVN has saved my butt many times.  I have had situations where my working copy got corrupted some how.  No problem just go back to the last version.   

Its Free!!!

Cons:

Only very minor things if I did more research on the little things that bugged me I would probably find a solution.   There are more important things I need to fix in my workflow.

5. Just how often does your source control software screw up and cause you major pain?

Maybe a few times a year something weird happens.  Because TortoiseSVN is so widely used I have always found the solution to the problem very quickly on line.  I have never had a problem that took more than an hour to fix.

 

I have never needed to branch and merge.  I just go in one line.  If I need to go back to a previous version I can and then continue on.  That being said I have never need to do that but it is nice to know I can.

 

I found this nice article that compares Git and SVN

https://backlog.com/blog/git-vs-svn-version-control-system/

Edited March 2, 2021 by ASTDan

[rharmon@sandia.gov]

On 2/25/2021 at 1:26 PM, G-CODE said:

Bob, I can't help but wonder if you might be mixing up terms here. If you're talking about using code from one project in another you might be thinking about Submodules (Git) or Subrepos (Mercurial).

Branching is typically done within the same project with the assumption that whatever work is done on the branch will get merged back into something considered the main or master. In LabVIEW, I suspect most of us try really hard not to modify the same file in multiple branches since merging VI's isn't as straightforward as merging text files. You might branch something to work on a feature that you're not ready to deploy, but you want to be careful not to also modify the same file in another branch because when it comes time to combine everything back into one (merge), the source code can't automatically reconcile a file that has changes in multiple branches. It leaves you in the position to decide which of the changes is the one to keep and which do you want to throw away or the worst case scenario - you think there might be unique changes in both of those edits that you need to figure out how to combine into one.

Eric

Eric,

I think you are exactly right... My thoughts of a branch was I have a software package and probably 90% of that code will be used in another project. I was thinking I would just branch off the second project and make the necessary changes to make the second project work. It would not be my intension to ever re-unite the branches. 

Thank you for catching my mistake... You have probably saved me from a future huge headache....

[rharmon@sandia.gov]

Thought I'd give a quick update on where I'm at.... But first a HUGE Thank You to everyone here... I can't express what a fantastic resource you guys are. 

I decided to try Tortoise SVN, mostly because everyone seemed to say it was the easiest to use, for a beginner in SCC I thought that very important. So far so good... I created a repository on my computer and (terminology is going to bite me here) Imported my project. It all appears to be fine so far... I know small steps.... This week has been crazy busy.. I'm hoping to actually change some vi's today and see how that goes. 

Next question...  Where to keep the repository... I'm just far enough in that if I needed to start over with a new repository I wouldn't be so bad. I actually tried to start the repository on a TeamForge site but got an error something about Tortoise SVN not supported something to do with DAV whatever that is. I plan to look into this a bit more today. But back to the question... I've tried using a LabVIEW Project that was on a network drive at work, and working from home was painful. LabVIEW would lock up looking for the network drive sometimes for up to 20 seconds... Drove me crazy... This is going to surprise everyone, but I'm horrible at backing up my laptop. So keeping the repository on my laptop worries me a lot. If I decide to keep it on my laptop I can set it up to sync on a networked drive at work. I don't think this would upset LabVIEW too much, But that is yet to be determined. Other then the obvious that I need to backup my laptop. Any other concerns about keeping the repository on my laptop?

Thanks again to everyone... You are all amazing....

 

[LogMAN]

2 hours ago, rharmon@sandia.gov said:

I was thinking I would just branch off the second project and make the necessary changes to make the second project work. It would not be my intension to ever re-unite the branches. 

What you describe is called a fork

Forks are created by copying the main branch of development ("trunk") and all its history to a new repository. That way forks don't interfere with each other and your repositories don't get messy.

[crossrulz]

I always stored my SVN repositories on a network drive that was constantly being backed up (I think most IT setups do it nightly).  The issue with SVN is that you cannot do any commits or reversions if you cannot access the repository.  So if you don't have access to the server, SVN won't do much.  That is one of the good things with GIT: you have the remote and the local repository.  You can commit and revert locally all you want and then eventually push your updates to the remote repository when you can.

[ASTDan]

I store all my Repositories on my laptop.  I have a repository for each project.  I have been doing this for years and it works great.  I need the repository on my laptop so  I can go to customer sites to do installs and still have SCC.

Now about backups.

I used to use Windows backup for years but Windows discontinued it.  I now use Aomei backupper https://www.aomeitech.com/aomei-backupper.html.  I have the paid version.  I back up to a Network attached storage that has 2 hard drives RAID together.  I backup every day and keep a 60 day history.  I then back up the back up to an external hard drive and store that in a water proof fire proof safe.  I try to do that every week but it doesn't always happen.  I looked into storing on the cloud but I have to much data.

IMHO you NEED to backup.  You also need it to happen automatically so you don't have to deal with it.  Aomei does a good job and is very easy to use.  I like it better than Windows backup.  You can use whatever you want just make sure you use something and it is automatic.  I really like my NAS.  It is a western Digital My Cloud.  Very easy to use and I like the RAID feature.  The cloud would be fine to.  There are a lot of services that will host your data and there are backup programs that can automatically handle that for you.