[MPlayer-DOCS] [PATCH] How to do regression testing using CVS

[The Wanderer]

On 11/27/2005 05:32 AM, Guillaume POIRIER wrote:

> Hi,
> 
> Please find in attachment the last revision of the patch. I believe
> I've addressed all comments.
> 
> On 11/27/05, The Wanderer <inverseparadox at comcast.net> wrote:
> 
>>> +If you have lot of hard disk free space (a full compile currently takes
>>> +100 Mb), copy the oldest known working version before updating it; it will
>>> +save time if you need to go back.
>> 
>> As noted above, the number has not been changed. Also, you didn't 
>> address the question of whether we use "MB" or "Mb" (or even make
>> any distinction between them).
> 
> "MB" is used on the rest of the doc, so I switched to MB.
> 
> Also, I did change the sentence to: "(a full compile currently takes 
> 100 MB, and around 300-350 MB if debugging symbols are enabled)".
> 
> Is that any better? I believe it is.

Yes, that's better.

> +cvs update -PAd -D "2004-08-23"
> +</screen>
> +The date format is YYYY-MM-DD HH:MM:SS.
> +Using this date format ensure that you will be able to extract patches
> +in a way that will be compatible with the
> +<ulink url="http://mplayerhq.hu/pipermail/mplayer-cvslog/">MPlayer-cvslog archive</ulink>.

I think you missed part of the point of my previous comment. The reason
for the "ensure that ... will be compatible" line is *because* there was
the time-zone reference; if you omit the explicit time zone when
attempting to get a specific date from Wine CVS, you will not
necessarily get the exact snapshot you want. As I said, I've experienced
that myself. (I'm not sure it makes a difference in practice what time
zone is used, although it might, but using none can definitely cause
problems.) If you're not going to include the time-zone identifier at
all, you shouldn't really include the "compatible" sentence either.

> +If you have lot of hard disk free space (a full compile currently takes
> +100 MB, and around 300-350 MB if debugging symbols are enabled), copy the
> +oldest known working version before updating it; this will save time if
> +you need to go back.

Minor, and certainly not worth re-posting over, but I think I'd prefer
"free hard disk space" here.

> +(It's better to run 'make distclean' before going back in time, so you
> +have to make everything if you don't back up the older version).

...now that I think about it, this is unclear... what it means is that
"because it is a good idea to run 'make distclean' before attempting to
compile an earlier version in the same source tree, you will have to
recompile everything after coming back to the present; if you want to
avoid that, you need to back up the current version" (and no, this is
*not* a suggestion for a phrasing to commit, it's too awkward), but it
doesn't explain why it's a good idea to run "make distclean", and there
are at least two possible meanings for "so" in that context but no
indication which one is intended.

Try something like "It is usually necessary to run 'make distclean'
before recompiling an earlier version, so if you do not back up your
original source tree, you will have to recompile everything in it when
you come back to the present.". That isn't ideal, but is at least
functional. (Because the term "back up" was not used in the previous
sentence, it might be a good idea to say "make a backup copy" instead.)

And there's no need to re-post again unless you write a new section of
text somewhere as a result of this; if all you do is make the latest
round of changes, then feel free to commit the result as far as I'm
concerned.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.