RFC: future gfortran development and subversion

[Steve Kargl]

I fear the impending switch to subversion will have a
negative impact on the future development of gfortran
due the rather limited number of people who actually
supply patches and the sudden increase in hardware
requirements.   For example, I find

troutmask:sgk[204] du -sh gcc40 gcc41 trunk
241M    gcc40   <-- CVS 4.0 branch
275M    gcc41   <-- CVS mainline
694M    trunk   <-- svn mainline

gfortran on 4.0 and mainline are sufficiently out of sync
that the backport of changes is becoming difficult.  
Additionally, some of us, who have large changes or test 
large changes, have more than one copy of CVS mainline.

With the impending branch of 4.1, this will look like

241M    gcc40   <-- CVS 4.0 branch
275M    gcc41   <-- CVS 4.1 branch
275M    gcc42   <-- CVS mainline

which is tolerable (even with a few copies of mainline
for large change sets).  But, svn would give

694M    svn40   <-- svn 4.0 branch
694M    svn41   <-- svn 4.1 branch
694M    trunk   <-- svn mainline

Now add one or two additional svn directories for large
change sets and this becomes intolerable.  (Before anyone
spews "disk space is cheap", I'll gladly accept any scsi
U320 disks you wish to send to me).

Now, to my proposal for future gfortran development 
post 4.1 branching.  When (if) svn becomes the source code
revision tool, I propose that all future work be done
solely on mainline.  No individual patches can be merged
into 4.1.  The 4.0 branch will be dead.  Periodically,
say bi-weekly or monthly, we do a merge from mainline
into 4.1.  The aim is to keep 4.1 and mainline sufficiently
in sync and to minimize the requirements of additional
hardware (except for the day or two required for the merge)
and to maximize our time investment.

-- 
Steve