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