Mail Archives: cygwin-developers/2001/09/24/09:39:13
The thoughts here are derived from my experience with squid
development...
I find that being able to create numerous small cvs branches for
specific development tasks has made a significant difference to the
squid development rate. Pretty much _everything_ that is new or
non-trivial is developed on a branch first, and then brought into HEAD.
This allows developers to collaborate on new things without breaking
HEAD, and also has meant that HEAD breaks very rarely. Like cygwin,
squid is widely used (most common http proxy server) and breakage is
equally bad.
I'd like to be able to do the same thing with cygwin. Specifically I'd
have liked to create a branch for the daemon experimentation, and one
for the umsdos stuff I started on, and one for the pthreads change to
critical sections. The key being that the development branches are free
wheeling, few rules, and are expected to get broken regularly...
Users are given some scripts that create branches, merge branches (ie
take all the changes to HEAD since the last merge and apply to this
branch), create patchs against parent branches (with cvs fluff removed),
and close branchs (create a final patch, delete intermediate tags and
the branch itself).
Now for _my_ convenience I can mirror cygwin locally, and sync up the
sources.redhat and my local cvs repo's - there are some very nice cvs
scripts Henrik Nordstrom has created that do all that automagically,
with the occasional human input to resolve the rare conflict (The HEAD
of the destination repo is _never_ committed to locally). (With squid,
the active development goes on at a separate cvs tree
cvs.devel.squid.org, and the production tree with the released tags, and
end user HEAD is at cvs.squid.org, which is why the sync scripts exist).
That separation is purely optional though.
Or, with Chris' blessing we could do something similar. I'm happy to put
in the effort to 'borrow' the squid scripts and adapt the documentation
to align with the cygwin 'way'.
The two main reasons I think this is worth considering, is that
* (for squid at least) it has made a difference in the number of
contributors.
* It has increased the quality of HEAD committed code by allowing longer
periods of experimentation for a given feature, _with peer review_ and
with source control of the experiments.
So I leave this open for discussion, thoughts, flames etc.
Rob
- Raw text -