4 ms·

I'm on an internship through my University, writing a report for my current employer (as a requirement of said internship program) about their current centrali

by Sunlis 14y ago

I'm on an internship through my University, writing a report for my current employer (as a requirement of said internship program) about their current centralized version control solution (Perforce) and comparing it to a distributed one (Git). Finding sources explaining why Git is "better" is easy, but finding any one arguing the other side is proving to be incredibly difficult. Are there simply no benefits to using a centralized system, or is no one bragging about them like all of these Git fans?

eli 14y ago
Sure, there are tons of benefits to a central repository. I think that's actually what most people want from a VCS (IMHO). And you can set up policies that make Git act more like Perforce (but not so much the other way around). The primary reason I switched my last employer from SVN to Git is because we frequently found ourselves in merge-conflict hell. Our workflow under Git was really very similar to our workflow under SVN.
kemayo 14y ago
It's worth noting that Git is often used as a centralized VCS. A central server is picked as the authoritative one (e.g. GitHub, or a server at your company) and the team pushes/pulls almost entirely to/from that server. In that common scenario, the difference between Git and whatever VCS it's replacing are really entirely in the UI.
chimeracoder 14y ago
Git was not originally meant as a VCS - it was meant to be a platform for other VCSs. For that reason, you can essentially write a wrapper on top of git to turn it into a centralized VCS that acts similarly to Perforce/SVN/etc., by enforcing a certain workflow that essentially eliminates merge conflicts. Of course, you lose a lot of the power of git when you do this (the same power that's responsible for many posts like these), but to cut a long story short: it's not an apples-to-apples comparison.
stonemetal 14y ago
One of the draw backs that typically gets mentioned about current distributed systems is the lack of locking which makes managing un-merge-able (binary) files impossible to manage correctly. This is why you will not hear of many game dev studios using git, version controlling art assets is fairly common in such situations and perforce handles it like a champ. DVCSs in general tend to have performance issues with large files, I know mercurial warns you about the performance implications of storing anything over 10MB. A bit old(2009) so it may have changed, but here is a rant about the scalability of git vs perforce. http://stevehanov.ca/blog/index.php?id=50 http://stevehanov.ca/blog/index.php?id=50 and a little newer post on git scalability issues: http://news.ycombinator.com/item?id=3548824 http://news.ycombinator.com/item?id=3548824
xyzzyb 14y ago
There was a post last week that you might be interested in: https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ https://steveko.wordpress.com/2012/02/24/10-things-i-hate-ab...

by Sunlis 14y ago

eli 14y ago

Sure, there are tons of benefits to a central repository. I think that's actually what most people want from a VCS (IMHO). And you can set up policies that make Git act more like Perforce (but not so much the other way around). The primary reason I switched my last employer from SVN to Git is because we frequently found ourselves in merge-conflict hell. Our workflow under Git was really very similar to our workflow under SVN.

kemayo 14y ago

It's worth noting that Git is often used as a centralized VCS. A central server is picked as the authoritative one (e.g. GitHub, or a server at your company) and the team pushes/pulls almost entirely to/from that server. In that common scenario, the difference between Git and whatever VCS it's replacing are really entirely in the UI.

chimeracoder 14y ago

Git was not originally meant as a VCS - it was meant to be a platform for other VCSs. For that reason, you can essentially write a wrapper on top of git to turn it into a centralized VCS that acts similarly to Perforce/SVN/etc., by enforcing a certain workflow that essentially eliminates merge conflicts. Of course, you lose a lot of the power of git when you do this (the same power that's responsible for many posts like these), but to cut a long story short: it's not an apples-to-apples comparison.

stonemetal 14y ago

One of the draw backs that typically gets mentioned about current distributed systems is the lack of locking which makes managing un-merge-able (binary) files impossible to manage correctly. This is why you will not hear of many game dev studios using git, version controlling art assets is fairly common in such situations and perforce handles it like a champ. DVCSs in general tend to have performance issues with large files, I know mercurial warns you about the performance implications of storing anything over 10MB. A bit old(2009) so it may have changed, but here is a rant about the scalability of git vs perforce. http://stevehanov.ca/blog/index.php?id=50 http://stevehanov.ca/blog/index.php?id=50 and a little newer post on git scalability issues: http://news.ycombinator.com/item?id=3548824 http://news.ycombinator.com/item?id=3548824

xyzzyb 14y ago

There was a post last week that you might be interested in: https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ https://steveko.wordpress.com/2012/02/24/10-things-i-hate-ab...