[MITgcm-devel] Comment on "recent changes"

[Martin Losch]

Hi Ed and Jean-Michel,

are you still sharing an office? Or did you have someone put a wall in 
to split it into two separees?

I like the suggestion about poetic CVS-comments (nice challenge) but I 
agree with Jean-Michel, that checking in stuff should always involve a 
comment!

Martin

On Jul 7, 2005, at 1:01 AM, Ed Hill wrote:

> On Wed, 2005-07-06 at 17:39 -0400, Jean-Michel Campin wrote:
>> Hello Ed,
>>
>> I disagree with your last check-in:
>> (aim.5l_cs/input/data & aim.5l_cs/input.thSI/data)
>> because it makes harder for users who start with this set-up and
>> parameter files, and want to do a longer simulation with mnc,
>> to know what they need to change (because I assume that they
>> don't want to duplicate the output, and before turning on mnc,
>> will have to remove/comment the line you just added).
>> This is what I think (but might not be the only one to think
>> like this).
>> And if, for the purpose of testing, you need do have both
>> MDSIO & MNC output files, why don't you add this just in your
>> own version ?
>
> Jean-Michel,
>
> OK, heres a win/win compromise: lets keep the outputTypesInclusive in
> the data files but comment them out with a "#".  That way, they can be
> quickly turned on for my testing and you get to have exactly the 
> default
> behavior that you want.
>
>
>> And to come back to the 1rst thing of this morning:
>>> It's just a detail, but it helps to clarify what has been modified
>>> in the code, when only modified files are checked-in
>>> (on the cvs webb, diagnostics_readparms.F, diff between version
>>> 1.13 and 1.12: - No changes -)
>> and your answer:
>>> With CVS, its basically impossible to check in a change thats a zero-
>>> diff.  It just doesn't work.  So, what you're complaining about is a
>>> failure of the ViewCVS program to correctly parse and display the
>>> difference.
>> I was not complaining about a cvs failure, but really that I find
>> easier to follow the changes that have been made in 1 file, when
>> only modified files are checked-in (I mean, not just blanks added
>> or removed from place to place, but true modifications), especially
>> when the cvs-commit message does not describe what has been changed.
>> (In this particular case, diagnostics_readparms.F, I would have 
>> expected
>>  something like: "add blanks to look nicer").
>
>
> Better yet, we could all write our CVS comments in verse:
>
>   Ragged Fortran bits!
> Begging but few spaces to
>   fix its crookedness.
>
> Ed
>
> -- 
> Edward H. Hill III, PhD
> office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
>              Cambridge, MA 02139-4307
> emails:  eh3 at mit.edu                ed at eh3.com
> URLs:    http://web.mit.edu/eh3/    http://eh3.com/
> phone:   617-253-0098
> fax:     617-253-4464
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel