Rubberduck: Remove Source Control Integration?

[rubberduck203]

I was reading #3756 and a thought came to my mind.
Is it time to remove the experimental Source Control Integration and just recommend that users use the apparently well working export feature?

I think removing it has a number of benefits.

• We’re tied to Git. Export allows users to use whichever VCS they like.
• It would remove the need for maintaining hundreds, if not thousands of lines of source.
• It would remove the need to maintain a relatively fast moving dependency.

Given the limited resources of the project, coupled with the fact that the original author of the subsystem (me) hasn’t been able to contribute in a number of years, maybe it’s time to let go of this time suck.

Letting it go would allow the team to focus on what Rubberduck is good at, parsing and inspecting code.

Thoughts?

[retailcoder]

The thought has occurred to me more than once... I'd happily kill it and watch it burn, yes... along with every single open issue about it...

I think it can be in-scope though - eventually...

[rubberduck203]

So, to avoid too much backlash, we should probably blast the idea out on twitter and give users a chance to weigh in. Link back here. Mind doing that?

[retailcoder]

Done: https://twitter.com/rubberduckvba/status/962087965102170115

[KDGundermann]

I'm using the great OasisSVN Tool (https://dev2dev.de/) so it would be ok for me to remove source control from Rubberduck

[EBrown8534]

@rubberduck203 @retailcoder I know I don't participate much in this project, but I'd vote to kill it with fire, from a logistics standpoint. (I'd offer to maintain that particular subsystem if I had more than 20 minutes a week that I could devote to it, but such is not the case.) Building an SC subsystem is difficult, and as Chris mentioned, it's currently limited to Git. Rubberduck doesn't necessarily _need_ the SC integration, because users can add the folder with the workbook / project to source control themselves. Yes, it may be more painful (using the git CLI, as an example), but it allows them all the freedom they need.

My vote: burn it, if resources allow consider reimplementing it at a future date (but only if it can be generalized to allow any SC "plugin").

Also, Mat does have a point that it can be in scope eventually, the problem is that without a dedicated maintainer (because it is a HUGE system) it's tough to manage with the limited resources. I'd say the risks of keeping it far outweigh the benefits at this point. (Maybe one day it can be revisited.)

[Inarion]

I don't have a twitter account, so can't vote there, but I guess it can't hurt to voice my opinion here:

For me the possibility to easily export my projects to a text-based format is far more important than having a specific source control system available within RD. (Most of what I code has to stay within the confines of our network environment, so we're rolling with our own SVN.)

In short: I wouldn't miss source control in RD, if it was gone. From a feature standpoint it's certainly nice to have, but not as important as many of RD's other features.

[rubberduck203]

Okay then. We’ll remove the feature.
Here’s the problem I have though.
I don’t have a proper dev env to actually do the removal myself.

How do we move forward here @retailcoder?

[rubberduck203]

I’ve begun closing old issues tagged source control.
I’ll work through them as I have spare moments.

I considered mass closure, but some of them may still be relevant to the export feature, so I feel I should review them all.

[rubberduck203]

Reopening this until I triage the remaining open issues.

[Vogel612]

Awaiting the removal of SC advertising from RD Web, I consider this issue done

[rubberduck203]

Thanks for cleaning the rest up. Let’s close this.