This is the mail archive of the mailing list for the GCC project.

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

Re: Fortran ChangeLogs merge

>Sure.  I just didn't think it necessary to supply patches to delete
>files.  Should that, in fact, be done?

Deleting files is a "different thing" in a shared environment -- you
need to make sure the deleted file has the exact contents you thought
they had, in case somebody has recently added something between the
time you last checked (in this case, moved stuff into ChangeLog) and
the time the delete actually happens.

(This was one of the little "discoveries" I made long ago when I took
over the implementation, and thus had to re-do the design, of a
queueing-routine package at Pr1me.  Not only had the original design
not provided for a client deleting a queue entry only if its contents
matched the client's representation exactly, it had not provided for that
check for writing either!  So a client's Read/modify/Write, or Read/Delete,
sequence could be interrupted at the "slashes" by another process that
did its own Read/Modify/Write, changing the queue entry into something
the client, were it forced to re-read, would modify a different way, or
perhaps choose not to delete.  For a system that was to form the basis for
batch-job, print-request, and email processing, among other things, that
could have been disastrous -- since it'd lead to nearly-impossible-to-
reproduce bugs that showed up only on very loaded systems, making users
question the entire system's viability.)

I don't know what this implies about sending a complete patch to
delete a file to egcs-patches, other than that, if somebody else
is going to do the commit, that should be required, otherwise, it
is basically just up to how people feel about how this situation
should be handled.  (E.g. I don't see any technical reason for Jeff
to say more than "I deleted" to egcs-patches -- sending
its complete contents along isn't really necessary in that case,
but might still be convenient.)

        tq vm, (burley)

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