From: Joseph Koshy <jkoshy@us...> - 2009-11-27 10:49:02
I recently came across a description of the way the Twisted (Python)
project develops their code and thought that it would be a good fit
for our project too:
In a nutshell, the core of the system is:
1) /trunk always builds and passes its tests. This allows people to
'svn cp trunk' and start work with the assurance that the code will
be in a sane state.
2) Work happens on SVN branches; one SVN branch per
There would a ticket associated with every change.to trunk. The
ticket serves a "top level container" referencing everything needed
to understand the change; e.g., links to wiki pages, lists of
related tickets, lists of related source changes etc.
3) Work gets folded back into /trunk after review. The main goal of
the review is so that at least one more person has fully understood
the proposed change. Of course, bugs would also be caught by the
Since code in branches is separate from /trunk, a developer need
not wait for the reviewer and can start on another work item (i.e.,
another branch) right away.
As a concrete example, let us say we want to create manual pages for
our tools and libraries. We would:
* Create a ticket [#27 in this case].
* Create a branch with "svn cp trunk branches/27-manualpages"
The convention being to name branches using the pattern
TICKET#-SHORTDESCRIPTIVENAME, so that people can know at a glance
where to go to find out more information.
* Do the work under branch "27-manualpages"; ticket #27 would track
the state of this work.
* Once done and reviewed, the changes would be merged back to /trunk.
The invariant maintained for /trunk is that it always is in a sane
* The work branch can then be "svn remove'd" to clean up the namespace