Re: new snapshot patches

[Rik]

Thomas Weber wrote:
> On Wed, Mar 25, 2009 at 08:01:30AM -0700, Rik wrote:
>   
>>> Subject:
>>> new snapshot
>>> From:
>>> "John W. Eaton" <address@hidden>
>>> Date:
>>> Tue, 24 Mar 2009 13:25:33 -0400
>>> To:
>>> octave maintainers mailing list <address@hidden>
>>>
>>> To:
>>> octave maintainers mailing list <address@hidden>
>>>
>>>
>>> As I mentioned recently, I would like to make a new snapshot this
>>> week.  Are there any patches or bug reports that should be addressed
>>> before I do that?  I know about the one Ben posted earlier today.  I
>>> would also like to try to fix the problem with the SKIP parameter when
>>> writing to existing files (we should skip and not write NUL in that
>>> case).  Is there anything else?
>>>   
>>>       
>> 3/25/09
>>
>> John,
>>
>> I've put a bunch of changesets for the documentation up on the Savannah
>> tracker.  There are 49 .texi files to review and I'm about 1/3 of the
>> way through.  It takes about an hour per .texi file because when I need
>> to make a change I have to hunt through the code to discover whether the
>> texinfo came from a .m file, a .cc file, or somewhere else.  I'm
>> thinking of going ahead and doing all the .m files at once.  
>>     
>
> I might be missing the obvious, but how about doing the change in one go
> and using
>       hg record
> afterwards?
>
>   
The problem is the association of specific .m files with a specific
.texi file.  In order to keep a patchset reasonably focused on a single
problem I was only modifying one .texi file and the associated files
that fed documentation information into it.  There are about 900 .m
files and keeping track of the fact that scripts/general/flipud.m is
documented in matrix.texi but scripts/general/isscalar.m is documented
in numbers.texi grew too hard.  It is easier to simply spell and grammar
check the entire scripts/general directory and check in the changes.  As
I understand 'hg record', to apportion changes between different commits
I would still need to know how to divide up the .m files which is what
takes a good bit of time.

Cheers,
Rik