This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, fortran/libgfortran] Fix PR22390 (FLUSH statement)


Janne Blomqvist wrote:
>>Janne, this is a nifty little patch.  I've read through it
>>quickly and will runs some tests tomorrow.  I think I've
>>ask before, do you have write access to cvs?
> 
> 
> Nope.
> 
> 
>> If not, we
>>clearly need to fix this.
> 
> 
> Um, ok, how do I proceed? IIRC Toon has been handling these things,
> and he recently posted that he'll be offline for a few weeks due to
> hardware failure or somesuch.


>From <http://gcc.gnu.org/cvswrite.html>:

If you already have an account on sources.redhat.com, please send email to
overseers(at)gcc.gnu.org with a request for access to the GCC repository.
Include the name of the person who is sponsoring your access. Else use this
form to supply your SSH public key (which you can generate via the ssh-keygen
program) and other details.

Now I don't know if I'm in a position to sponsor your access, but every
appointed maintainer is, so I'm adding Steven Bosscher and Paul Brook to the
CC list, so that they can express their support :-)

>>Paul B, this patch removes 3 files and incorporates their
>>content into a new file.  Are there any special GCC requirements
>>in removing files (so cvs history is maintained)?
> 
> 
> Ah, I didn't think about the cvs history aspect. In that case, maybe
> combining those files isn't warranted. I just think it's annoying to
> work with lots of small files, but that's a matter of taste I
> guess. One minor pitfall is that in that case the file can't be named
> flush.c since then flush.lo conflicts with flush.lo from
> intrinsics/flush.c.
> 
> Anyway, IIRC gcc is going to switch to svn in the not too distant
> future, so maybe it makes sense to postpone the combination until then
> (AFAIK svn preserves history through renaming).

svn preserves history through renaming, but what counts in this case is that
it has repository versions which allow you to see the whole changeset, so that
you can know that the same code disappeared from file A and reappeared in file
B at the same time.  Changesets are automatically generated from the CVS logs
in a cvs2svn transition, so there's nothing to loose if we move stuff around
between files now instead of in a few (wishful thinking) weeks.

I haven't yet looked at the patch in depth as I believe Steve is looking into it.

Thanks,
- Tobi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]