Re: gcc branches?

[Tom Lord <lord at emf dot net>]

The following exchange is typical of many that cross the gcc list, and
thus, at least iconically, it represents a lot of people's time and
money.


   per:
   > Any ETA on when the gcc trunk will be open again for
   > non-bug-fixes?  I've got two space-reduction patches
   > I'd like to check in soon, and I'm trying to figure out
   > whether to check in to the 3_4-basic-improvements-branch
   > or wait until the trunk is open.

   > Will someone automatically merge in changes from the 3.4
   > branch into the trunk, or are each of us responsible for
   > our own merges?  I hope the former, though if there are
   > any conflicts that may be difficult.


   zack:
   > I have been doing trunk->branch merges all along, and I
   > intend to merge the entire branch back to the trunk at once,
   > shortly after the 3.3 branch is created.  It will need
   > testing though.  (I've got x86, sparc, and hppa test
   > platforms lined up; other architectures would be helpful.)


If the project was using `arch', I think you'd have an easier time.

Since it is cheap and easy to create branches (spanning repositories),
you (per) would have the option of forking the trunk and committing
your changes there.  By hand, or (better), automatically given some
infrastructure work first, as the trunk evolves, you could have the
evolving trunk re-merged nightly with your changes so that any
conflicts are noticed early, giving you some flexibility about when
you fix them (or about who fixes them).  When the freeze is off,
merging the changes back to the trunk would go smoothly.  (Of course
you can do similar things using any revision control system, arch
simply makes it easier than most and is designed with infrastructure
automation in mind.)

I've been thinking it makes sense to automate things as follows
(though feedback from gcc developers might change my mind):  

*) developers have their own repositories

  Particularly, developers working on new features rather than those
  doing release integration/engineering.  One advantage of this is
  that each feature developer can work on a branch of the trunk, using
  `star-merge' as described above, to catch conflicts as early as
  desired.  Another advantage is that feature developers can decide to
  merge their branches with one another early, simplifying integration
  into the trunk down the road -- shortening freeze periods.  Another
  advantage is that early adopters of features can gain access to them
  earlier, more easily.


*) the gcc web site catalogs all those repositories

  You can browse and review features under development, for example.
  You can get email notifications as a feature evolves.  You can run a
  cron job that will detect (early) when two features-in-progress
  touch overlapping files and are likely to conflict.  These features
  can be offered even to developers who do not have write access to
  the primary repository.


*) favored developers get automated testing

  By adding a header field to some of your log messages, you can
  trigger overnight testing of your branches.  This facility can be
  safely extended even to developers who do not have write access to
  the primary repository -- and in that way, it can reduce the
  workload on those who do have write access and have the job of
  merging in other people's patches.


*) trunk merges get automated vetting

  By adding a header field to some of your log messages, you can 
  declare that a branch is ready to be merged into the trunk.  
  This implies, for example, that you have resolved all conflicts
  on your branch -- that if the trunk remains stable, the merge will
  be clean.  Automatically, then, the merge can be validated and
  tested before, finally, being committed to the trunk.

  Of course, if two developers publish conflicting changes at the same
  time, human intervention is necessary for at least one of those
  change sets -- but here, too, arch can help: by helping to
  automatically detect the condition, to notify the relevant
  developers, and to provide them with good tools for fixing the
  conflicts.


I also note that "CVS is wedged" posts occur frequently on the gcc
list.  With a modest up-front investment to finish `arch 1.0' and test
the heck out it, I think it is clear (from the designs of both
systems), that arch's admin costs will be lower -- repositories will
break less often (and perhaps, essentially, never).  There has been
some sentiment on this list to move to svn -- I encourage design
inspections and comparisons (contemplating admin costs and robustness)
there as well.

Finally,


   per:
   > Great!  Have you (or Mark?) tested merging the 3.4 branch
   > with the cp-parser-branch


Such testing is straightforward to automate with arch and a status
inquiry like this one should be answered by automatically generated
web pages.


-t