[ 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
