Up on the bright clear view, in line with my personality. Ha ha ha.
Why not optimistic about git it?
First, let's look at the background git generated.
Linus git is developed, the initial aim is to manage the source code for Linux systems. This is a hierarchical centralized version control system, not online parrot distributed version control system. The following detailed description.
Linux development habits, usually with software companies to develop different habits:
Linus, or add a small amount of other key personnel, responsible for maintaining the Linux kernel code, they may be involved in the development of their own, others may accept the offer of packages (software enhancements, or bug fixes) , merged into the existing code library. In an interview with packages provided by others, expect the other party has been fully tested, the code is no obvious problems, the code specification also comply with the appropriate regulations , otherwise, these key personnel, the right to refuse this package is added to the Linux core code . Also, the same function, there may be multiple parties to submit contributions to the package, several key personnel can choose one of them to join the Linux kernel code.
Single package itself may be complicated by the small amount of another batch of key personnel, plus a large number of developers, they are also accustomed to above, in an interview with a smaller level packages provided by others, expect the other party has been fully tested, Code no obvious problems, the code specification also comply with the appropriate regulations , otherwise, these key personnel, the right to refuse this package added to this package. Also, the same function, there may be multiple parties to submit a smaller contribution level package, several key personnel can choose one of them, adding this package.
This is the hierarchical centralized development model.
The problem is that most companies, software or set up temporary project team are not to develop the habit of Linux core group, expand the work .
For the average company, any employee for each hour of work, are labor costs, is money. To avoid the loss of the code due to the hard loss, many companies require, every programmer, every day before work, you need to check-in code into the code base , it does not compile, comments, together, still check-in code into the code base .
The company is also unlikely to have to ask: the guy who, you are responsible authority module, all development, testing complete , the then into the repository; the guy who, you are responsible for the orders module, all development, testing complete , the then into repository ...
Therefore, the management mode Linux core code, does not have the versatility.
"Distributed" is the word, is the buzzword, but the vast majority of cases, no. Without the need for "distributed", and insist on applying "distributed" way of doing things will only bring more convenient, pay more labor costs.
EJB is a good example.
Concepts, techniques, compared to the previous similar software technology / product / architecture, are excellent. After being widely abused, we have found that this stuff too hard to use, whether it is under development forum, employee attendance, enterprise information management, e-commerce, or other, in most cases, will only increase the difficulty and led the development of workload.
This is because, "distributed" technology is only suitable for use under a "distributed" scene.
Of course, for single employees, learning an inappropriate fashion technology, can enhance the competitiveness of individuals looking for work; for the company, the team, the use of an inappropriate fashion technology, increasing the overall cost, reduced in disguise the company's competitiveness. Not worth using, you see what areas stood.