Re: Another patch with a massive renderingdifference.

On Sun, Nov 02, 2003 at 11:42:30AM +0300, Igor V. Melichev wrote:

> I suggest retain committing such patches in SAME DAY,
> because CVS has no method to checking out revisions with
> a smaller time quantum.

This is actually not true; the cvs -D option supports a variety of 
date/time formats with a once second precision. From the man page:

Examples of valid date specifications include:
                        1 month ago
                        2 hours ago
                        400000 seconds ago
                        last year
                        last Monday
                        yesterday
                        a fortnight ago
                        3/31/92 10:00:07 PST
                        January 23, 1987 10:05pm
                        22:00 GMT

> 
> ----- Original Message ----- 
> From: "Dan Coby" <[email protected]>
> To: "Igor V. Melichev" <[email protected]>; "Ray Johnston"
> <[email protected]>
> Cc: "Miles Jones" <[email protected]>; "Jack Moffitt"
> <[email protected]>; <[email protected]>
> Sent: Sunday, November 02, 2003 7:15 AM
> Subject: RE: [gs-code-review] Another patch with a massive
> renderingdifference.

Earlier, Dan Coby wrote:

> > My question are:  How do I check in my change and update the
> > baselines without possibly losing a real regression caused
> > by all of the current outstanding regressions?  When will I
> > be able to check in my changes safely?

This is obviously not trivial. The best thing, waiting for a clean run 
aside, is to manually update the baseline 'underneath' the current 
regressions by updating to the results from a gs build that exhibits 
your progression, but not the current regression (i.e. apply your patch 
to a version previous to the current regression and generate the new 
baseline from that). Obviously this could be prohibitively tedious with 
the current number of differences.

It's also possible to not update the baseline for the files with 
existing differences, and just work out with jack and the engineer(s) 
responsible for the existing differences so that they understand your 
progression and can approve it as well whenever the regression is fixed.

Both are obviously some work, which is why our approach to date has just 
been to wait for a clean-ish run.

FWIW,
 -r