Re: RFC: future gfortran development and subversion

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

[ I've added gcc@ to the CC list and reproduced the message in full, FX
already got the "buy a bigger harddisk" answer there, I think it makes sense
to show that other people care about this, too ]

Steve Kargl wrote:
> 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).

If you have multiple directories containing the same branch it should
be possible to set up a very small svk repository which essentially doesn't
more than keep a common pristine copy for all the two or three checkouts you
want to keep (i.e. no or only very little history).  A little information on
using svk has made it into the wiki, but it's not yet very informative.

> 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.

This should actually be feasible with svn merge, before on cvs this would have
been a tedious task.  I fear that this approach will fail to insufficient
volunteer time, though.

- Tobi