Misc doc updates.
diff --git a/documentation/cvs-regression.sgml b/documentation/cvs-regression.sgml
index 9f2a2f5..1871db8 100644
--- a/documentation/cvs-regression.sgml
+++ b/documentation/cvs-regression.sgml
@@ -2,7 +2,7 @@
<title>How to do regression testing using Cvs</title>
<para>
- written by (???)
+ written by Gerard Patel
</para>
<para>
(Extracted from <filename>wine/documentation/bugreports</filename>)
@@ -20,8 +20,8 @@
<para>
Get the 'full cvs' archive from winehq. This archive is
the cvs tree but with the tags controlling the versioning
- system. It's a big file (> 15 meg) with a name like
- full-cvs-<last update date> (it's more than 100mb
+ system. It's a big file (> 40 meg) with a name like
+ wine-cvsdirs-<last update date> (it's more than 100mb
when uncompressed, you can't very well do this with
small, old computers or slow Internet connections).
</para>
@@ -31,7 +31,7 @@
untar it into a repository directory:
<screen>
cd /home/gerard
- tar -zxffull-cvs-2000-05-20.tar.gz
+ tar -zxfcvs-dirs-2000-05-20.tar.gz
mv wine repository
</screen>
</para>
@@ -53,8 +53,25 @@
<para>
Note that it's not possible to do a checkout at a given
date; you always do the checkout for the last date where
- the full-cvs-xxx snapshot was generated.
+ the wine-cvsdirs-xxx snapshot was generated.
</para>
+ <para>
+ Note also that it is possible to do all this with a direct
+ Cvs connection, of course. The full cvs file method is less
+ painful for the winehq cvs server and probably a bit faster
+ if you don't have a very good net connection.
+ </para>
+ <note>
+ <para>
+ If you use Cvs directly from the winehq.com server, do not
+ forget to add to your <filename>.cvsrc</filename> file:
+ </para>
+ <screen>
+ cvs -z 3
+ update -dPA
+ diff -u
+ </screen>
+ </note>
</listitem>
<listitem>
<para>
@@ -63,11 +80,14 @@
Now update this image to the date you want:
<screen>
cd /home/gerard/wine
- cvs -d $CVSROOT update -D "1999-06-01"
+ cvs -d $CVSROOT update -D "1999-06-01 EDT"
</screen>
</para>
<para>
- The date format is <literal>YYYY-MM-DD</literal>.
+ The date format is <literal>YYYY-MM-DD HH:MM:SS</literal>.
+ Using the EDT date format ensure that you will be able to
+ extract patches in a way that will be compatible with the
+ wine-cvs archive : http://www.winehq.com/hypermail/wine-cvs
</para>
<para>
Many messages will inform you that more recent files have
@@ -91,74 +111,37 @@
make depend && make
</screen>
<para>
- When you have found the exact date when a bug was added to
- the cvs tree, use something like :
- <screen>
- cvs -d $CVSROOT diff -D "1999-07-10" -D "1999-07-12"
- </screen>
- to get all the differences between the last cvs tree
- version known to work and code that first displayed the
- misbehavior.
- </para>
- <note>
- <para>
- I did not include flags for <command>diff</command>
- since they are in my <filename>.cvsrc</filename> file:
- </para>
- <screen>
- cvs -z 3
- update -dPA
- diff -u
- </screen>
- </note>
- <para>
- From this diff file, particularly the file names, and the
- <filename>ChangeLog</filename>, it's usually possible to
- find the different individual patches that were done at
- this time.
- </para>
- <para>
If any non-programmer reads this, the fastest method to get
at the point where the problem occured is to use a binary
search, that is, if the problem occured in 1999, start at
mid-year, then is the problem is already here, back to 1st
April, if not, to 1st October, and so on.
</para>
+ <para>
+ If you have lot of hard disk free space (a full compile takes
+ currently 400 Mb), copy the oldest known working version before
+ updating it, it will save time if you need to go back (it's
+ better to make distclean before going back in time, so you
+ have to make everything if you don't backup the older version)
+ </para>
+ <para>
+ When you have found the day where the problem happened, continue
+ the search using the wine-cvs archive (sorted by date) and a
+ more precise cvs update including hour, minute, second :
+ <screen>
+ cvs -d $CVSROOT update -D "1999-06-01 15:17:25 EDT"
+ </screen>
+ This will allow you to find easily the exact patch that did it.
+ </para>
</listitem>
<listitem>
<para>
- The next step is to start from the last working version
- and to dig the individual contributions from
- <ulink url="http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/">
- http://www.integrita.com/cgi-local/lwgate.pl/WINE-PATCHES/</ulink>
- (where the Wine patches mailing list is archived)
- </para>
- <para>
- If the patch was done by the Wine maintainer or if it was
- sent directly to his mail address without going first through
- <ulink url="mailto:wine-patches@winehq.com">wine-patches</ulink>,
- you are out of luck as you will never find the patch in
- the archive. If it is, it's often possible to apply the
- patches one by one to last working cvs snapshot, compile and test.
- If you have saved the next candidate as
- <filename>/home/gerard/buggedpatch1.txt</filename>:
- </para>
- <screen>
- cd /home/gerard/wine
- patch -p 0 < /home/gerard/buggedpatch1.txt
- </screen>
- <para>
- Beware that the committed patch is not always identical to
- the patch that the author sent to wine-patches, as
- sometimes the Wine maintainer changes things a bit.
- </para>
- <para>
- If you find one patch that is getting the cvs source tree to
- reproduce the problem, you have almost won; post the problem on
- <systemitem>comp.emulators.windows.wine</systemitem> and there
- is a chance that the author will jump in to suggest a fix; or
- there is always the possibility to look hard at the patch until
- it is coerced to reveal where is the bug :-)
+ If you find the patch that is the cause of the problem, you have
+ almost won; report about it on <systemitem>comp.emulators.windows.wine</systemitem>
+ or susbscribe to wine-devel and post it there. There is a chance that the author
+ will jump in to suggest a fix; or there is always the possibility
+ to look hard at the patch until it is coerced to reveal where is
+ the bug :-)
</para>
</listitem>
</orderedlist>
