dimi at users.sourceforge.net
Sun Aug 27 23:41:44 CDT 2006
ChangeSet ID: 1156740104699485644073324
Module name: docs
Changes by: dimi at sc8-pr-cvs9.sourceforge.net 2006/08/27 21:41:44
en : winedev-otherdebug.sgml
Mike McCormack <mike at 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
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)
- <title>How to do regression testing using CVS</title>
+ <title>How to do regression testing using Git</title>
A problem that can happen sometimes is 'it used to work
@@ -371,117 +371,63 @@ int main (void)
- 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).
- untar it into a repository directory:
-tar -zxf full-cvs-2003-08-18.tar.gz
-mv wine repository
+ 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.
- 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:
-mv wine wine_current (-> this protects your current wine sandbox, if any)
-cvs -d $CVSROOT checkout wine
+git bisect start
+git bisect good wine-20041019
+git bisect bad wine-20050930
- 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.
- 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>.
- 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:
-cvs update -PAd -D "2004-08-23 CDT"
+./configure && make clean && make depend && make
- 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">
- 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:
+git bisect bad
+ and if it does not, run:
-cvs update: tsx11/ts_xf86dga2.c is no longer in the repository
+git bisect good
+ 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.
- <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:
+git bisect visualize.
- Now proceed as for a normal update:
-make depend && make
- 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.
- 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
- 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:
-cvs update -PAd -D "2004-08-23 15:17:25 CDT"
+git bisect reset
- This will allow you to find easily the exact patch that
- did it.
@@ -557,7 +503,7 @@ return cfd;
what has been tested already by running gcov on the file.
To do this, do the following:
-cvs checkout wine
+git clone git://source.winehq.org/git/wine.git wine
More information about the wine-cvs