Aleksey Bragin wrote:
Ideally (as I explained in #reactos today to blight_), I want the trunk itself be directly committable only by a very limited number of persons, and all developers should be committing to "some other place" at first, and then their patches merged by reviewers/testers (yes, manually, sometimes just reviewing may be enough to commit/ reject the patch, sometimes a thorough testing must be involved, maybe additional devs asked for a review).
blight_ called this as a "linux development model" with an intermediate branch - yes, maybe, why not?.
The worst case I see with doing this using SVN is that we have a lot of branches, which either depend on each other or are even incompatible to each other.
I remember what Alex proposed (those who don't, may look up ros-dev ML archives with a similar topic).
That development model sounds good, but I see a simple but annoying problem here: If we keep using SVN and a developer does a second patch to the same component before his first patch was committed, SVN's diff command will output a patch with the changes of the first and second patch.
Would there be any new prepositions? Maybe someone discovered a new CIS for SVN, or a decentralized VCS for patch submission and usual SVN for maintaining HEAD?
I recently read about Mercurial (Hg) and it sounds interesting. It's a very fast and decentralized VCS and would also solve the problems I mentioned above: We could have two repositories, one like the current trunk and another one only containing verified changes. Merging changes from one repository to the other one should be very easy with Hg. Also every developer would have his own repository when doing a checkout, so he can commit patches to it and later commit them all to the "playground trunk" or a branch or post a bunch of independent patch files to Bugzilla or wherever.
Unlike GIT, Hg also works quite well under Windows like SVN does: There exist command-line tools and TortoiseHg for Windows-Explorer integration. The only downside I see is the usage of Python, which might annoy developers who don't want to install (yet another) interpreter on their system.
Of course, the other way to work against these problems is focusing on automated regression testing. If we have a quite large test suite and could run that automatically, the regression Magnus introduced could probably be found as well without any human waste of time.
Best regards,
Colin