ChangeSet ID: 1156740104699485644073324 CVSROOT: /cvsroot/wine Module name: docs Changes by: dimi@sc8-pr-cvs9.sourceforge.net 2006/08/27 21:41:44
Modified files: en : winedev-otherdebug.sgml
Log message: Mike McCormack mike@codeweavers.com Update regression testing procedure to use Git.
Old revision New revision Changes Path 1.4 1.5 +34 -88 docs/en/winedev-otherdebug.sgml
Index: docs/en/winedev-otherdebug.sgml diff -u -p docs/en/winedev-otherdebug.sgml:1.4 docs/en/winedev-otherdebug.sgml:1.5 --- docs/en/winedev-otherdebug.sgml 28 Aug 2006 4:41:44 -0000 +++ /dev/null 28 Aug 2006 4:41:44 -0000 @@ -361,7 +361,7 @@ int main (void) </para> </sect1> <sect1> - <title>How to do regression testing using CVS</title> + <title>How to do regression testing using Git</title>
<para> A problem that can happen sometimes is 'it used to work @@ -371,117 +371,63 @@ int main (void) </para>
<orderedlist> - <listitem> - <para> - Get the <quote>full CVS</quote> archive from winehq. This - archive is the CVS tree but with the tags controlling the - versioning system. It's a big file (> 40 meg) with a name - like full-cvs-<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> - </listitem> - <listitem> + <listitem> <para> - untar it into a repository directory: - <screen> -cd /home/gerard -tar -zxf full-cvs-2003-08-18.tar.gz -mv wine repository - </screen> + Clone the <quote>Git</quote> repository from winehq. + It's more than 90Mb, so you it may take some time with + a slow Internet connection. </para> </listitem> <listitem> <para> - extract a new destination directory. This directory must - not be in a subdirectory of the repository else - <command>cvs</command> will think it's part of the - repository and deny you an extraction in the repository: + If you found that something broke between wine-20041019 and + wine-20050930 (these are [WWW] release tags). To start regression + testing we run: <screen> -cd /home/gerard -mv wine wine_current (-> this protects your current wine sandbox, if any) -export CVSROOT=/home/gerard/repository -cvs -d $CVSROOT checkout wine +git bisect start +git bisect good wine-20041019 +git bisect bad wine-20050930 </screen> </para> <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. - </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. + If you have exact date/time instead of a release you will need + to use sha1 IDs from <filename>git log</filename>. </para> </listitem> <listitem> <para> - you will have now in the <filename>~/wine</filename> - directory an image of the CVS tree, on the client side. - Now update this image to the date you want: + Having told Git when things were working and when they broke, + it will automatically "position" your source tree to the middle. + So all you need to do is build the source: <screen> -cd /home/gerard/wine -cvs update -PAd -D "2004-08-23 CDT" +./configure && make clean && make depend && make +./wine 'c:\test.exe' </screen> - </para> - <para> - The date format is <literal>YYYY-MM-DD HH:MM:SS</literal>. - Using the CDT date format ensure that you will be able to - extract patches in a way that will be compatible with the - wine-cvs archive - <ulink url="http://www.winehq.org/hypermail/wine-cvs"> - http://www.winehq.org/hypermail/wine-cvs</ulink> - </para> - <para> - Many messages will inform you that more recent files have - been deleted to set back the client cvs tree to the date - you asked, for example: + If the version of Wine that Git picked still has the bug, run: + <screen> +git bisect bad + </screen> + and if it does not, run: <screen> -cvs update: tsx11/ts_xf86dga2.c is no longer in the repository +git bisect good </screen> + When you run this command, Git will checkout a new version of Wine + for you to rebuild, so repeat this step again. When the regression + has been isolated, git will inform you. </para> <para> - <command>cvs update</command> is not limited to upgrade to - a <emphasis>newer</emphasis> version as I have believed for - far too long :-( + To find out what's left to test, try: + <screen> +git bisect visualize. + </screen> </para> </listitem> <listitem> <para> - Now proceed as for a normal update: - </para> - <screen> -./configure -make depend && make - </screen> - <para> - If any non-programmer reads this, the fastest method to - get at the point where the problem occurred is to use a - binary search, that is, if the problem occurred 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 - currently takes 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 <command>make - distclean</command> 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: + When you have found the bad patch and want to go back to the current HEAD run: <screen> -cvs update -PAd -D "2004-08-23 15:17:25 CDT" +git bisect reset </screen> - This will allow you to find easily the exact patch that - did it. </para> </listitem> <listitem> @@ -557,7 +503,7 @@ return cfd; what has been tested already by running gcov on the file. To do this, do the following: <screen> -cvs checkout wine +git clone git://source.winehq.org/git/wine.git wine mkdir build cd build ../wine/configure