SCC Role Call

[viSci]

It has been awhile (more like 6 years) since the great SVN, HG, GIT debate occurred in the LAVA community.  I thought it would be informative just to get a simple roll call of who has settled for what.  Rationales are optional, just wanted to get a head count...

[mje]

IBM Rational Team Concert. Because the bureaucracy hates us.

There's an insurgency at my company trying to get the Atlassian/GIT solution traction, but I may have already said too m--

[ensegre]

Git. Because my IT, begged for centralized SCC of some sort, settled for an intranet installation of gitlab, which I'm perfectly fine with. But I'm essentially a sole developer, so SCC is to me more for version tracking than for collaboration.

Tools: git-cola and command line. Reasonably happy with Gitkraken, using git-gui on windows as a fallback.

Edited June 8, 2017 by ensegre
add tools

[drjdpowell]

I use Hg, with TortoiseHg client, and Bitbucket to host the central repos.  

[smithd]

Git, specifically the open source Gitea/Gogs with sourcetree as my client.

[Taylorh140]

Currently SVN, tortoiseSVN.  (separated source code from executable). I would change to git, but i haven't decided the best implementation or client.

[Gab]

Presently Tortoise SVN

[bjustice]

Tortoise SVN with command line tools installed.  This lets me call SVN from the LabVIEW system exec, which I use for various applications

[LogMAN]

Atlassian/Git with SourceTree as client. Also getting Atlassian JIRA soon™ 

Git because it doesn't require server connection and is the fastest to work with in our case.
SourceTree because its easy to learn and useful for users with terminal phobia.

[Bryan]

We used to use Visual SourceSafe and built toolkits for our ATE systems to ensure we were running the latest versions of software (and to perform self-checks). 

My company tried to force IBM Rational ClearCase on our group but I was able to fight them off and am currently using SVN/TortoiseSVN.  Funny though, my company has started setting up SVN databases since so many people balked at ClearCase.

[Rolf Kalbermatter]

Tortoise SVN (+command line tools for a few simple LabVIEW tools) both at work as well as on a private Synology NAS at home.

[hooovahh]

Tortoise SVN.  I've used Mercurial, and Perforce too, but SVN is the one I'm most familiar with, and the setup was stupid simple.  I only use LabVIEW tools for performing a rename in a project and SCC at once.

[bbean]

SVN

[Tim_S]

Should be using SVN, but corporate IT broke the network in some obscure way so the only way can use SVN is on the server and not the development PCs. Used Hg for a bit on my development PC but had to stop as the standard laptop has a tiny SSD on it.   My final solution has been to not make mistakes which has the new challenge of staying humble while being perfect.

[A Scottish moose]

SVN, GIT is popular among the rest of the company (text based dev) but I haven't found any limitations in SVN that make the extra overhead of the GIT workflow worth it.  

[ned]

Apparently we're in the minority here - we're using Mercurial (TortoiseHg). It was set up before I started, it wouldn't have been my first choice. We now have most of our code in a single repository which has grown unmanageable so we're looking at other solutions, perhaps we should consider moving to SVN (based on responses here) while we're adjusting our repository structure. I like the idea of Mercurial, but delta-based versioning just doesn't work that well for binary files. I've used SVN a bit but most of my previous experience is with Perforce and that would be my first choice if I got to pick (and cost wasn't an issue).

[ShaunR]

Another SVN user here (Tortoise SVN client side). Only two functions are ever used, Commit and Revert

[JKSH]

20 hours ago, LogMAN said:

Atlassian/Git with SourceTree as client. Also getting Atlassian JIRA soon™ 

Git because it doesn't require server connection and is the fastest to work with in our case.
SourceTree because its easy to learn and useful for users with terminal phobia.

Git + SourceTree, for the same reasons as @LogMAN.

I'm not getting JIRA for LabVIEW work, but I'm part of an OSS community that does use JIRA.

[smarlow]

SVN with TortoiseSVN clent.

[PiDi]

SVN with TortoiseSVN for commercial projects.

Git with TortoiseGit for other projects. The more I use it, the more I like it - especially for things like local commits. I can commit "in-progress" code without worrying of breaking someone else's arrows

[A Scottish moose]

25 minutes ago, PiDi said:

SVN with TortoiseSVN for commercial projects.

Git with TortoiseGit for other projects. The more I use it, the more I like it - especially for things like local commits. I can commit "in-progress" code without worrying of breaking someone else's arrows

I would be interested in a deeper discussion on a LabVIEW implementation of Git source control.  I am the primary developer here so the overhead doesn't make sense... yet... I can see where it would start to shine in a multi-developer environment.  A discussion on the pros/cons of SVN vs. GIT would be an interesting (if geeky) discussion.

[smithd]

On 6/8/2017 at 9:53 AM, A Scottish Moose said:

SVN, GIT is popular among the rest of the company (text based dev) but I haven't found any limitations in SVN that make the extra overhead of the GIT workflow worth it.  

 

4 hours ago, A Scottish Moose said:

I would be interested in a deeper discussion on a LabVIEW implementation of Git source control.  I am the primary developer here so the overhead doesn't make sense... yet... I can see where it would start to shine in a multi-developer environment.  A discussion on the pros/cons of SVN vs. GIT would be an interesting (if geeky) discussion.

Below is not really a discussion of the pros and cons. To get a detailed and specific list, just google it. If there is a dead horse thats been beaten on the internet, its "git vs svn".

What I'm confused about is the "extra overhead" comment. You've said it twice but haven't provided any example of what you mean by this. There is a learning curve, absolutely, as with any tool, but I don't really see much if any additional overhead.

If you want to use git just like SVN with a central server there doesn't seem to be anything stopping you and the workflow is similar (you have to press "push" before every commit and "pull" before you begin work, but...). This is primarily how I've used it, with the additional features of local commits and branching (I like to commit several times per day even if the code is still broken). Because the projects are small, I've only ever had a few conflicts over the course of several years. I think this is the situation most of us are in, less than 5 people working on a given project.

Bigger projects with labview would have slightly more challenges with regards to coordination because of the lack of locking, but this is solvable through two things you should be doing anyway: communicating with your coworkers about what they are doing, and breaking things down into smaller projects. The best example I have of this is https://github.com/LabvieW-DCAF/ . There are 51 repositories by my count and while some are non-code (documentation, build scripts, etc) the development granularity keeps things easier to manage regardless of what source control you use.

And thats actually the point I wanted to make...I started out using SVN, I used perforce and currently use it for one project, and I've used git whenever possible since I switched over to it. Fundamentally the procedures involved in any of them are pretty similar (as shaun said, 'commit and revert'), but I keep returning to git because the 'killer feature' is serverless and non-locking usage. When I work on a feature the entire codebase belongs to me

Edited June 10, 2017 by smithd

[hooovahh]

I've not used git, but I hear some of these pros/cons.  The one I've heard is that git is sometimes better because it forces you to communicate with your developers to know what they are working on.  But if this were a servers side SVN thing with locks you'd know what other people are working on because, it's locked.  If you need to work on something that is locked, ask the person that locked it if they are done and can unlock it.  I don't need to track down every developer and ask what they are working on or if I can work on a code module.  If something is locked I want to work on I talk to that developer about it, if it isn't locked I'm free to do whatever.

The server-less side of things do allow for you to have the whole code base at your disposal, but you could do something similar with SVN when you aren't connected to a server.  You'll just have lots of things to resolve when you do get back online since there is a chance multiple people changed the same VI, just as you would with git.

Since I'm in the office 99% of my development time having it be server dependent is a non-issue, and that other 1% of the time I either VPN in, or I'm going onsite to deploy a system and will typically lock the whole project before going out, or not lock it, and the changes I make while offsite will need to be merged when I get back.

I was also confused by the overhead comments.  Do you mean work flow overhead?

[A Scottish moose]

If my comments are confusing it might be related to our corporate implementation of Git.  Perhaps I'm assuming some local habits are Git procedures and this is where the confusion comes from.  At our shop the source control, bug tracking, code reviews, and release tracking are all incorporated into the cloud service collab.net.  The Git rules are written as such that all these tools must be used.  SVN rules are not written as strict so it's more to my decision on implementation.  If I switched our LV libraries over to the Git system I'd have to take the whole system together, code reviews, bug tracking, and all.  Since I'm the only developer here this is a little more than my development needs at this point.  A git commits here requires 3 sets of eyes to agree to the quality of code.  Since I'm the only LV developer it gets tough to find two people to say 'ya that actor framework implementation looks great!'

I do see the value but LV hasn't quite gotten to that point for our office. Let me know if this clears up your questions.

Cheers,

 

[smithd]

I see, that makes sense. Yeah I wouldn't necessarily want to agree to that process either unless anyone here is aware of a code review tool that works nicely with labview. Having an integrated issue tracker can be nice though, as your commits can directly link to features.

3 hours ago, hooovahh said:

I've not used git, but I hear some of these pros/cons.  The one I've heard is that git is sometimes better because it forces you to communicate with your developers to know what they are working on.  But if this were a servers side SVN thing with locks you'd know what other people are working on because, it's locked.  If you need to work on something that is locked, ask the person that locked it if they are done and can unlock it.  I don't need to track down every developer and ask what they are working on or if I can work on a code module.  If something is locked I want to work on I talk to that developer about it, if it isn't locked I'm free to do whatever.

Well that assumes they left it locked on purpose which is the annoying problem i face especially with folks swapping back and forth between git and svn or p4. They go on vacation and everything is locked, as an example. As for the communication argument I would never argue that the lockless approach makes that easier but I do see it as an easily solved problem. I'd prefer a middle ground like a 'git flag' or something on a section of code, but i have no idea how it would work..

Edited June 12, 2017 by smithd