This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: future gfortran development and subversion
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Tobias Schl?ter <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: fortran at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 19 Oct 2005 12:16:50 -0700
- Subject: Re: RFC: future gfortran development and subversion
- References: <20051019183738.GA7927@troutmask.apl.washington.edu> <43569798.1000109@physik.uni-muenchen.de>
On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote:
> >
> > 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.
OK, I'll go read about svk. I scanned the svn docs for an
--exclude-dir= option or .svnrc file where excluding directories
could be done. So far, I've come up empty. I don't build nor
work in the ada, java, and C++ directories. It would be great
if we could tell svn to ignore certain directories to recover
wasted space.
> > 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.
You might be right. I have a large back log of patches in my inbox
that I need to review for mainline. It's getting to the point that
I simply lack the time and resources to track multiple branches, so
in the future I may only be able to provide review and approval
of gfortran patches for mainline.
--
Steve