Change most in-tree references from SVN to GIT.

Also, talk about "mainline" not "trunk".

The release.txt and release.sh files need more updates.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2825 b42882b7-edfa-0310-969c-e2dbd0fdcd60

BUGS

@@ -22,7 +22,7 @@ that may be important.
 - If the report is for a regression:
   - Include logs for both working and broken versions.
   - Find the precise version that caused the regression by binary search.
-    For example: if testing version 550 works but 600 fail, then try 575, etc.
+    You can use "git bisect" to expedite this binary search.
 
 If possible, please develop and attach a patch that helps to expose or
 solve the reported problem.  See the PATCHES file for more information

PATCHES

@@ -9,9 +9,8 @@ you're a member, despite what the list info page says.
 
 @section Patch Guidelines in a Nutshell
 
-The patch should be against svn trunk using an SVN
-diff. If you use git-svn, a git diff or patch is OK
-too; likewise a quilt patch, if you use quilt.
+Your patches should be against git mainline.  Submit output
+of "git diff"; equivalently, quilt patches are OK.
 
 It should be a "good patch": focus it on a single
 issue, and make it be easily reviewable. Don't make
@@ -34,18 +33,9 @@ Add yourself to the GPL copyright for non-trivial changes.
 
 To create a patch from the command line:
 @code 
-	svn diff >mypatch.txt
+	git diff >mypatch.txt
 @endcode
 
-See: @par
-	http://svnbook.red-bean.com/en/1.0/re09.html
-
-Remember to use "svn add" on new files first: @par
-	http://svnbook.red-bean.com/en/1.0/re01.html
-
-If you have a decent SVN GUI, then that should be
-able to create and apply patches as well...
-
 @section More Information on Patching
 
 The @ref primerpatches provides a more complete guide to creating,

README

@@ -74,13 +74,13 @@ A Note to OpenOCD Users
 -----------------------
 
 If you would rather be working "with" OpenOCD rather than "on" it, your
-operating system or interface supplier may provide binaries for you in a
-convenient package.
+operating system or JTAG interface supplier may provide binaries for
+you in a convenient-enough package.
 
-Such packages should be more stable than SVN trunk, where bleeding-edge
+Such packages may be more stable than git mainline, where bleeding-edge
 development takes place.  These "Packagers" produce binary releases of
-OpenOCD after the developers produces new "stable" versions of the
-source code.  Previous versions of OpenOCD cannot be used to diagnosed
+OpenOCD after the developers produces new "release" versions of the
+source code.  Previous versions of OpenOCD cannot be used to diagnose
 problems with the current release, so users are encouraged to keep in
 contact with their distribution package maintainers or interface vendors
 to ensure suitable upgrades appear regularly.
@@ -205,7 +205,7 @@ options may be available there:
 
   --enable-maintainer-mode  enable make rules and dependencies not useful
                           (and sometimes confusing) to the casual installer
-			  NOTE: This option is *required* for SVN builds!
+			  NOTE: This option is *required* for GIT builds!
 			  It should *not* be used to build a release.
 
   --enable-dummy          Enable building the dummy JTAG port driver
@@ -376,29 +376,36 @@ the following:
 Note that on Linux there is no good reason to use these FTDI binaries;
 they are no faster (on Linux) than libftdi, and cause licensing issues.
 
-=================================
-Obtaining OpenOCD From Subversion
----------------------------------
+==========================
+Obtaining OpenOCD From GIT
+==========================
 
-You can download the current SVN version with an SVN client of your
-choice from the following repositories:
+You can download the current GIT version with a GIT client of your
+choice from the main repository:
 
-   svn://svn.berlios.de/openocd/trunk
-or
-   http://svn.berlios.de/svnroot/repos/openocd/trunk
+   git://openocd.git.sourceforge.net/gitroot/openocd/openocd
 
-Using the SVN command line client, you can use the following command to
-fetch the latest version (make sure there is no (non-svn) directory
-called "openocd" in the current directory):
+Using the GIT command line client, you might use the following command
+to set up a local copy of the current repository (make sure there is no
+directory called "openocd" in the current directory):
 
-   svn checkout svn://svn.berlios.de/openocd/trunk openocd
+   git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
 
-If you prefer GIT based tools, the git-svn package works too:
+Then you can update that at your convenience using
 
-   git svn clone -s svn://svn.berlios.de/openocd
+   git pull
 
-Tips For Building From The Subversion Repository
-************************************************
+There is also a gitweb interface, which you can use either to browse
+the repository or to downlad arbitrary snapshots using HTTP:
+
+   http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd
+
+Snapshots are compressed tarballs of the source tree, about 1.3 MBytes
+each at this writing.
+
+
+Tips For Building From a GIT Repository
+---------------------------------------
 
 Building OpenOCD from a repository requires a recent version of the GNU
 autotools (autoconf >= 2.59 and automake >= 1.9).

README.Win32

@@ -40,7 +40,8 @@ Take note that different Linux distributions often have different MinGW
 installation directory.  Some of them also put the library and include
 into a separate sys-root directory.
 
-If there is a new svn version of libusb-win32, you can build it as well. 
+When the libusb-win32 repository is more current than its release code,
+you could build that instead.
 
 These are the instruction from the libusb-win32 Makefile:
 
@@ -93,5 +94,5 @@ To use ftd2xx:
         --with-ftd2xx-win32-zipdir=/path/to/libftd2xx-win32 \
         ... other options ...
 
-If you are using the SVN repository, see the README file for additional
+If you are using the GIT repository, see the README file for additional
 instructions about configuring and building OpenOCD.

bootstrap

@@ -20,6 +20,7 @@ autoheader
 automake --gnu --add-missing --copy
 )
 
-# AM_MAINTAINER_MODE requires SVN users provide --enable-maintainer-mode
+# AM_MAINTAINER_MODE requires --enable-maintainer-mode from everyone using
+# current source snapshots (working from GIT, or some source snapshot, etc)
 # otherwise the documentation will fail to build due to missing version.texi
 echo "Bootstrap complete; you can './configure --enable-maintainer-mode ....'"

doc/manual/primer/autotools.txt

@@ -22,14 +22,14 @@ cases, a fresh bootstrap may be still required.
 @subsection primerbootstrapcures Problems Solved By Bootstrap
 
 For example, the build system can fail in unexpected ways after running
-<code>svn update</code>.  Here, the <code>make maintainer-clean</code>
+<code>git pull</code>.  Here, the <code>make maintainer-clean</code>
 should be used to remove all of the files generated by the @c bootstrap
 script and subsequent build processes.
 
 In this particular case, one may also need to remove stray files by hand
 after running this command to ensure everything is rebuilt properly.
 This step should be necessary only if the @c maintainer-clean was run
-@b after altering the build system files with Subversion. If it is run
+@b after altering the build system files with git. If it is run
 @b before any updates, the build system should never leave artifacts
 in the tree.
 
@@ -61,7 +61,7 @@ experience errors when running @c make that some files cannot be found
 the problems.  The isssue is well-known and expected, if unfortunate.
 
 The OpenOCD project requires that all developers building from  the
-Subversion repository use the @c --enable-maintainer-mode option when
+git repository use the @c --enable-maintainer-mode option when
 running the @c configure script.  This option ensures that certain files
 are created during the build process that would normally be packaged in
 the distribution tarball.  The @c bootstrap script will remind you of

doc/manual/primer/patches.txt

@@ -6,10 +6,10 @@ for OpenOCD contributors who are unfamiliar with the process.
 @section primerpatchintro Introduction to Patching
 
 The standard method for creating patches requires developers to:
-- checkout the Subversion repository (or bring a copy up-to-date),
+- checkout the git repository (or bring a copy up-to-date),
 - make the necessary modifications to a working copy,
-- check with 'svn status' to see which files will be modified/added, and
-- use 'svn diff' to review the changes and produce a patch.
+- check with 'git status' to see which files will be modified/added, and
+- use 'git diff' to review the changes and produce a patch.
 
 It is important to minimize the changes to only those lines that contain
 important differences; do not allow stray whitespace changes into your
@@ -20,7 +20,7 @@ patches, and keep the focus to a single logical change.
 You can create a patch (from the root of your working copy) with a
 command like the following example: @par
 @verbatim
-svn diff > patch-name.patch
+git diff > patch-name.patch
 @endverbatim
 
 where @a patch-name should be something that is descriptive and unique.
@@ -29,8 +29,8 @@ The above command will create a patch containing all of the changes in
 the working copy; if you want to obtain a subset, simply provide the
 list of files to the command: @par
 @verbatim
-svn diff doc > <patch-name>-doc.patch
-svn diff src > <patch-name>-src.patch
+git diff doc > <patch-name>-doc.patch
+git diff src > <patch-name>-src.patch
 @endverbatim
 
 This will create two patches, each containing only those changes present
@@ -56,65 +56,20 @@ submission, sending your patch to the bit bucket on accident.
 @section primerpatchpreflight Developer Review
 
 Before sending in patches, please make sure you have updated to the
-latest version of the trunk (using <code>svn up</code>) before creating
+latest version of the trunk (using <code>git pull</code>) before creating
 your patch.  This helps to increase the chances that it will apply
 cleanly to the trunk.  However, the content matters most.
 
-When creating a patch using "<code>svn diff</code>", Subversion will
+When creating a patch using "<code>git diff</code>", git will
 produce a patch that contains all of the changes in your working copy.
 To manage multiple changes at once, you either need one working copy per
 patch, or you can specified specific files and directories when using
-<code>svn diff</code>.  Overlapping patches will be discussed in the
+<code>git diff</code>.  Overlapping patches will be discussed in the
 next section.
 
-The remainder of this section provides
-
-@subsection primerpatchprops Subversion Properties
-
-The Subversion attributes of files can be examined with commands like the
-following: @par
-@verbatim
-$ svn pl README
-Properties on 'README':
-  svn:eol-style
-$ svn pl tools/rlink_make_speed_table/rlink_make_speed_table.pl
-Properties on 'tools/rlink_make_speed_table/rlink_make_speed_table.pl':
-  svn:executable
-  svn:eol-style
-$
-@endverbatim
-
-@subsection primerpatchpropcrlf Native Line-endings
-
-Subversion checks out files marked with the attribute @c svn:eol-style
-set to @c native such that these files contain the default line ending
-style of the current host ('\\n' or '\\r\\n').  By using the proper line
-endings for different platforms, two different byte streams for the same
-file will be produced.
-
-@subsection primerpatchwincrlf Windows Patching Problems
-
-Because of the line-ending functionality, it may be correct when a fresh
-patch does not apply cleanly on the Windows platform.  This is because
-patches are created by SVN with UNIX line endings, so the context and
-changes will not appear to match the files with Windows line endings.
-
-In other words, the following command may @b not succeed because @c foo
-has its @c svn:eol-style property set to @c native: @par
-@code
-svn diff foo | patch -R
-@endcode
-
-The following series of commands will work: @par
-@code
-svn diff foo | unix2dos | patch -R
-@endcode
-
-This is not a bug.
-
-@todo Does Subversion's treatment of line-endings for files marked with
-svn:eol-style=native continue to pose the problems described here, or
-has this been magically solved?
+@todo Does git's treatment of line-endings behave sanely?
+Basically, the repository should use newlines internally,
+and convert to/from CRLF on Windows etc.
 
 @section primerpatchseries Patch Series
 
@@ -132,9 +87,8 @@ simply a matter of taste or familiarity; your mileage may vary.
 
 Packages such as @c patchutils, @c diffutils, and @c quilt are among
 those that have proved themselves invaluable for these type of tasks.
-Others take their patch management a step further, tracking the
-Subversion repository with git-svn and employing GIT conventions and
-methodologies for development.
+Others take their patch management a step further, using stkgit or
+some other framework on top of git.
 
 @subsection primerpatchseriesinterdiff Using @c interdiff
 
@@ -144,22 +98,22 @@ patches.  This command can be used to manage the creation of trivial
 patch series.  For example, the following sequence of commands will
 produce three patches: @par
 @verbatim
-$ cd openocd-head/
-$ svn up && svn st
-At revision NNNN.
+$ cd openocd/
+$ git pull
+...
 $ <<<start changes for patch #1>>>
 ...
 $ <<<finish changes for patch #1>>>
-$ svn diff > series-1.patch                         # patch #1 is easy
+$ git diff > series-1.patch                         # patch #1 is easy
 $ <<<start changes for patch #2>>>
 ...
 $ <<<finish changes for patch #2>>>
-$ svn diff > series-1+2.patch                       # create patch 1+2
+$ git diff > series-1+2.patch                       # create patch 1+2
 $ interdiff series-1{,+2}.patch > series-2.patch    #   1 ~  1+2  => #2
 $ <<<start changes for patch #3>>>
 ...
 $ <<<finish changes for patch #3>>>
-$ svn diff > series-1+2+3.patch                     # create patch 1+2+3
+$ git diff > series-1+2+3.patch                     # create patch 1+2+3
 $ interdiff series-1+2{,+3}.patch > series-3.patch  # 1+2 ~ 1+2+3 => 3
 @endverbatim
 
@@ -173,19 +127,14 @@ efficiently than can be managed by hand.  For out-of-tree work projects
 that require such patch management, @c quilt provides an indispensable
 tool for solving the problem.
 
-@subsection primerpatchseriesgit Using @c git
-
-The @c git revision control system provides a tool for tracking
-Subversion repositories.
-
 @section primerpatchsubmit Submitting Patches
 
-Write access to the OpenOCD Subversion repository is limited to
+Write access to the OpenOCD git repository is limited to
 contributors that have demonstrated the ability to produce clear,
 consistent, and frequent patches.  These individuals are responsible
 for maintaining the integrity of the repository for the community.
 
-Thus, commits to the Subversion repository must be handled by one of
+Thus, commits to the git repository must be handled by one of
 these maintainers.
 
 Patches must be sent to the OpenOCD developer mailing list: