Hello, The discussion on smoking and branching is driven by the need to maintain quality across a wide range of compilers and "target"(1) machines. I would add a couple of points.
0. When working through the review process the tool I wanted the most was a
simple way
to test cross-platform/compiler after I had passed the test-suite on my
machine. I
have both a Linux and a Darwin platform but that is a fraction of the list.
Waiting for some other kind soul to test things out for you on other
platforms was slow,
and would have been impossible without the usual suspects in #parrot .
Could patches in a very specific format be mailed to a build farm, where
compile
tests/smoke tests would run against the HEAD + patches in the mail ?
The reply could contain the test results , and even some sort of "stamp", if
it passed,
that I could attach to the RT.
With the build/smoke farm merit badge the reviewer of the changes can
look at the "meat" of the changes without robotic and mind-numbing
repetition of
the test-suite. The time could be spent better considering the merits of the
changes.
1. branching and merging in SVN is very primitive. tracking the last common
ancestor
must be done in the changelogs, failure to do so is a disaster.
* This is an existing merge tool that matches up with the parallel
development
requirements: http://www.orcaware.com/svn/wiki/Svnmerge.py
* This seems to be the official subversion page on merge-tracking
http://subversion.tigris.org/merge-tracking/
* cherry picking never seems to work quite as well as you would
want. The weak link is diff/patch.
Unless the patches are extremely fine-grained you many times end up
hand-editing hunks or doing post patch merges. I have tried
subversion,git, hand-editing hunks (diff mode), and ediff.
Only the last patch in a sequence of dependant changes can be
modified without causing a tidal wave (good analogy
http://en.wikipedia.org/wiki/Tsunami) of rejects. The end result
is changes are not broken up, merger falls back on pass/reject.
Are you ready for cherry picking ?
1. Is every whitespace cleanup, bug fix, refactor, and feature
change a separate commit ?
2. Are your feature changes layered in even more separate commits ?
each one compile/test-suite checked ?
A. Why not wait until SVN has proper support for merging ?
B. definitely need a tool of some sort to ensure the last common ancestor
information is not mistakenly dropped.
C. If there is a branch that is forked why not make it the stable branch ?
The HEAD assuming the parrot project is flying along like we would all
want it to is going to/does have heavy commit traffic on it.
The number of changes you want in the stable is low. Put the expensive
review checking on the merge "from head" -> "to stable", so the work-set
can be reduced by a quick scan of the changelog to cherry pick which
things
could even be considered canidates.
my 2 cents on the branching issue.
I have been developing for myself tools to enhance
svn for cherry picking, branching etc. I have working code; but that
project is on the back-burner since diff/patch is the real problem,
cherry picking/merging are the symptoms. All RCS systems use the patch/diff
hunk as the fundamental change mechanism. There is just to much information
dropped in a diff to handle conflicts cleanly, or rather the wrong kind of
information to resolve conflicts in source code as well as it could.
With that said I think the build/smoke farm would give developers a tool to
widely
test their changes, without expecting them to have a room full of computers.
The branching model could be used, but it must be used in a way that is not
going
to push the current tools beyond their working use-cases, if that happens it
will take alot of manual labor to compensate.
Cheers,
Mike Mattie
(1) Autoconf lingo for the machine the program runs on.
signature.asc
Description: PGP signature
