For the love of God, is there a modern VCS besides TFS, mercurial, and git (mainly git, fuck git)?
1 13 Oct 2016 12:37 by u/dolphonebubleine
Git is popular but it's fucking horrible. I'm forced to use it at work despite it being more difficult to use, slower, more dangerous, less integrated, etc than TFS. I used mercurial at my last job. Mercurial was not great but no where no as asinine as git.
I checked Wikipedias list of Version Control Systems and most of them seem very old. The only VCS that seemed half-way modern, besides the one I mentioned, was bitkeeper.
I'd like a GUI interface (no fucking command line), that works on windows and linux, and doesn't demand you invest hours into learning it. You know, LIKE TFS (save the linux bit). I don't really give a shit about VCS and hate that I have to.
18 comments
6 u/tame 13 Oct 2016 14:01
I used git for the past three years, finally got tired of its inexplicable bullshit, and migrated back to SVN. It's great, it's simple, it's quick, it works.
Just use SVN.
0 u/Morbo 14 Oct 2016 01:15
SVN is a good compromise. It may be dated but it does the job well. I have trusted it for years to be a solid personal use SCM but have also used it in my job when we needed an unobtrusive yet substantial version manager. I think that SCM should be a simple tool that does not take massive amounts time and management. SVN fits that is nicely.
1 u/rms_returns 17 Oct 2016 19:12
SVN is a centralized VCS though, its not distributed, which means, the moment you commit a change, you push it to the centralized server. In other words, its good for cases where one individual is committing one module or project, but not so good when a whole lot of people are working on a single project.
The problem here is that there is only one canonical copy of the code which is your SVN server. If I commit something in file1.cpp, then your copy of the file becomes stale and you have to checkout that file from the server - this becomes a nightmare when both you and me change a large number of same files and they need to be merged.
The whole reason that Linus Torvalds brought git in the first place is so that multiple people in a team can work on different pieces of the same project, each person's copy of git repo is as much canonical as the other one. Thus, one programmer can make a quick change in their part of the code, and send a change-request (CR) that the other can then accept and merge! This CR thing isn't quite possible with SVN.
0 u/tame 18 Oct 2016 00:09
Absolutely true, and as I said in another post, it makes git really good for the specific use case you describe, with a huge team working in a very parallel and decentralised manner. (In fact, Linus wrote git specifically to deal with this case, so it ought to be good at it!) And if that's what you're doing, then by all means, use git.
In my experience, though, that kind of environment is very rare. Usually when people say "I need version control" they're working solo or in a small team. Concurrent modification can be avoided with a trivial amount of communication, and the extra capability that git provides for industrial-strength merging just isn't used often enough to justify the extra workload.
1 u/hereonachair 13 Oct 2016 14:33
GIT is pretty damn intuitive and simple to use given the inherent complexity of version control. It has many functional advantages over SVN and few if any disadvantages, but if you're not interested in any of the things that set it apart then it can seem slightly harder to use for no apparent benefit. That being said git is probably the easiest tool to use out of those in the modern toolbox stack, so if you're having problem with it I'd love to see your rant towards garbage like Vagrant, Chef, Docker, Jenkins and etc that are both annoying but are also commonly employed by teams.
0 u/foltaisaprovenshill 13 Oct 2016 20:17
Have you looked at PlasticSCM?
0 u/sparts 14 Oct 2016 01:56
You sound like a fucking retard. Maybe computers aren't for you?