My team has been using CVS for ages. I'm new to the team and can't imagine how my colleagues are working in this environment. I am thinking of proposing to change to git.

I found this amazing video of Linus explaining to Google engineers why git is better and I thought I'll show it to them:
https://youtu.be/4XpnKHJAok8

What do you guys say about my idea? Do you have anything that can help me?

what are the problems with CVS and more importantly what are the benefits of using git over cvs?

You need to sell this.
Because nobody got time for a video in the office.

@heyheni yes I have got those jotted down as points. Along with details about how it will improve our existing workflow

@xnor do you have benchmark numbers for your higher ups?

Company X integrated git in 2011 within 3 months their development sprints increased X number and problems in production decreased by 70%. That's an efficiency improvement in time and resources by 35% in just 3 months. In 2014 Company X started to use Continous Integration and Deployment. Which rose the developer satisfactory level by half and brought even shorter development cycles. What took us in 2010 months we can achieve within hours. In 2015 Company X established a DevOps culture which attracts top talent which made Company X marketleader in [business field].

We can achieve that too!

What you think that will happen: you teach them Git, and after a week, everyone is so much happier than before.

What really will happen: versioning used to be a simple task, but no longer. Devs still need to meet deadlines, but get caught in a jungle of missing data abstraction, confusing commands and stupid error messages.

So they write down a few safe commands, and whenever there is an error, they copy their files elsewhere, delete the project, clone and copy back their files. Version control of branches now happens in form of local directories. When the associated fuckups occur, everyone but you will be totally clear how this could happen.

@Fast-Nop sad but true. Unless you've got support from high up and some budget for training.

@heyheni I like your idea. I may not be able to get info about other companies, but I can definitely get info from other teams in my company that use git

@Fast-Nop yeah I thought about that. They already have convoluted scripts that abstract CVS commands. The time people will take to get used to git will be more than the time it will take to convince them and migrate our existing code to git.

Also, Linus' introduction is actually an argument for SVN and not Git because SVN is CVS done right. Sure, if you are Linus and have a huge project with over a thousand devs world wide, there is no way SVN can ever work. But if you are a small team, then SVN is perfectly fine and much simpler.

@Fast-Nop lol this hits close to home

And finally.. as new team member, your first and most important concern should be how to get productive as quickly as possible. Means, getting familiar with the product, implementing features and deliver bugfixes. That's what the team needs right now, or else they wouldn't have needed a new team member at all.

Instead, going to fumble around with the toolchain and adding up a considerable amount of unexpected work to the team is really not a good way to introduce onself as new team member.

@Fast-Nop I haven't used SVN but from what he says it still lacks proper branching support, which I feel, is the important thing missing in our workflow.

By the time I tell them about git, it will be almost an year since I joined. So, I think I will be fine.

@xnor uh what, I work with SVN branches. Also, the video is from 2007, that was 12 years ago.

@rantalicious SVN is perfectly fine as long as you don't actually need a _D_VCS. Whether that's the case should be an open ended evaluation for the company in question.

@rantalicious Git isn't better, on the contrary, because of its complexity alone. Versioning should be as simple as possible because it's just a helper tool. For understanding SVN, you only need to understand directories, which is trivial.

Want a proof how much Git's UI sucks? Just look at Github. OSS devs flock in droves to a platform that is both closed and centralised. It doesn't even allow properly using Git, to the point where Torvalds stopped accepting kernel pull requests done via Github. The whole point of Github is bypassing Git's UI.

@rantalicious the CLI of course because that's where you sooner or later will end up in troubleshooting. This would be even more difficult after having used a GUI because then you also would have to figure out what really has happened.

I can just say that I'm a happy SVN user, and versioning is the simple task that it ought to be. I can readily do that even when I havn't been using SVN for two months at all because I'm doing a lot more than only coding.

However, we're not working with a huge team on a megaproject, so that also explains the different experience.

It's always about fear if change, downtime, migrations, Learning curve.

Also, why us CVS worse than git?

@mundo03 no branches. Everyone is editing the master

@Fast-Nop I have some githubs projects, I only use their UI to create, admin or find projects

Everything else I do on cli.

Github's UI does provide an easy way to get started in git, but it is by no means a substitute of the git cli.

The extras are what matter, bugs, PR, code review when you choose a 'cloud git-thing'