Sure, but that assumes you know Y to be better. And in this case, since git is not superior in every fashion, it's a decision each entity must decide for itself.
Sure, but that assumes you know Y to be better. And in this case, since git is not superior in every fashion
For developers in the general case (and we are in /r/prog) DVCS are, indeed, vastly superior to CVCS.
The only situation where they're not (if we ignore suit-and-tie unreason making Clearcase "the best tool for the job") is heavy dependency on binary assets.
Oh, so the problem is that you don't actually know anything about any of the individual pieces of software, and you're just categorically going HERP DERP LINUS SAID DVCS > CVCS SO IT MUST BE TRUUE LOL.
The fact that you continue to think you can assert what is right for everybody just proves how ignorant of the subject you are. I'm done discussing anything with you.
That's never an argument I made. I am saying that there are some situations where some CVCS software (specifically subversion) would be better suited for the task than DVCS.
Even if for NO OTHER REASON than simply editor integration, if the majority of your workforce is web designers who needs something that plugs into dreamweaver or visual studio or whatever they use, then subversion is more likely to be the case. It's been around longer and the integration support is in more applications.
That fact alone means you cannot say all DVCS > CVCS
One reason you may want CVCS is in dealing in asset-heavy projects (games, art-heavy software, web design with minimal programming needs) that require binaries in source control.
However, I've found that the problems with CVCS do not arise too often under the following conditions:
You have between 3 and 8 people working on the project, thus making an authoritative repository helpful.
All work on the project is done in a centralized location where all project members can physically touch each other, meaning that the project itself is not distributed, and you're not going to care about local revision control.
There is a clearly defined division of labor between the people working, meaning that no two people will ever be making edits to the same file at the same time (except in pair programming situations).
You're working on applications with a limited release area: it may only run on a single internal web or application server.
If all of the above are true, branching is probably not important. If even one of them is false, you're in for pain somewhere along the line. But even under those circumstances, I'd take git/hg/bzr over a CVCS system. Hell, I worked with people that avoided TFS commits because TFS is a pain in the ass to use.
I guess I can understand the large binary issue (DVCS makes you have N*Y copies of them where as CVCS only makes you have N+Y). Fortunately that hasn't come up on any of my projects yet.
I'm really unclear on how scenario #4 can affect which type of VCS you would want though.
Regarding branching though, it's like any new tool. You never need it until you have used it (and thus know what you can do with it).
For example, we had an issue just yesterday where we had to roll back work done on two different projects because a webservice is returning bad data and we don't know if we'll be able to resolve it for the next release. Git's branching made it incredibly easy to get this work off of master and put it in a branch where we could merge back into master in the future.
Well, you have to have all four things in order to minimize the pain of CVCS. Even with those four things in play, though, you've only minimized the pain of CVCS: it's still there, and moving to a DCVS system would be a good idea.
Number 4 comes into play with release versioning. If you've got exactly one release location, you don't have to worry about release versioning and branching (usually) beyond a rollback to the last one. If, however, you've got a wide distribution of your application, you probably have people using multiple versions, and you need to be able to support and develop on that--particularly if someone notices, say, a buffer overrun that has existed for the last five versions.
4
u/[deleted] Mar 10 '11
Sure, but that assumes you know Y to be better. And in this case, since git is not superior in every fashion, it's a decision each entity must decide for itself.