Changes between Version 3 and Version 4 of Git/WhyGit
- Timestamp:
- Feb 5, 2011, 3:47:21 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Git/WhyGit
v3 v4 3 3 Subversion works well for Boost's version control needs, so why should we move to Git? 4 4 5 That's really the wrong question, however. Here are the real questions: 5 That's really the wrong question. Here are the real questions: 6 7 == How can Boost grow to encompass many more libraries without becoming unwieldy? == 8 9 Some aspects of Boost are already unwieldy, such as the trunk vs release-branch split, and the regression testing system. Users want to be able to install only the portions of Boost they are interested in, yet get dependencies automatically. 10 11 Decoupling the individual Boost libraries would be very helpful, or even essential, to solving those big picture problems. Decoupling would also make it easier for individual libraries to follow their own development cycles and development styles. 12 13 Decoupling is often called "modularization". See www.ryppl.org for one take on Boost modularization. 6 14 7 15 == Why should Boost move to a distributed version control system? == 16 17 * Enables decoupling and modularization. While decoupling and modularization is certainly possible with non-distributed version control, a distributed version control system makes it much easier, and many large open-source projects have moved or are moving to DVCS. 8 18 9 19 * Decouples the Boost mothership repository from developers' local repositories: … … 17 27 * Scales up to a much larger number of libraries: 18 28 19 * Encourages wider participation and ease patches. The ability to submit pull requests provides a smoother way for a new developer to ease into participation, and makes it easier to submit and apply non-trivial patches. (I'm pretty sure that has been the experience of other projects, but a citation or two would be useful.)29 * Encourages wider participation and eases patches. The ability to submit pull requests provides a smoother way for a new developer to ease into participation, and makes it easier to submit and apply non-trivial patches. (I'm pretty sure that has been the experience of other projects, but a citation or two would be useful.) 20 30 21 31 * Eliminates much or all of the need for the sandbox.