diff mbox series

doc: Replace references to SVN with those to Git

Message ID ri6sgkg8xby.fsf@suse.cz
State New
Headers show
Series doc: Replace references to SVN with those to Git | expand

Commit Message

Martin Jambor Jan. 15, 2020, 5:05 p.m. UTC 
Hi,

when going over stuff linked from the SummerOfCode wiki page, I found
out that doc/install.texi still refers to Subversion.  The following
patch replaces SVN to Git almost mechanically.  Tested with make info
and make html.  OK for trunk?

And then perhaps for the opened release branches too?

Thanks,

Martin


2020-01-15  Martin Jambor  <mjambor@suse.cz>

	* doc/install.texi (Prerequisites): Replace references to SVN with
	references to Git.
	(Downloading the source): Likewise.
	(Configuration): Likewise.
	(Building): Likewise.
---
 gcc/ChangeLog        |  8 ++++++++
 gcc/doc/install.texi | 22 +++++++++++-----------
 2 files changed, 19 insertions(+), 11 deletions(-)

Comments

Gerald Pfeifer Jan. 16, 2020, 7:38 a.m. UTC | #1 
On Wed, 15 Jan 2020, Martin Jambor wrote:
> when going over stuff linked from the SummerOfCode wiki page, 
> I found out that doc/install.texi still refers to Subversion.

We've got a fair number of references left in various places;
working through that slowly and appreciate your help!

> The following patch replaces SVN to Git almost mechanically.

I'm wondering whether we can/should see where to use a more
generic term in a few cases; let me propose some such cases.

> OK for trunk? And then perhaps for the opened release branches too?

Yes (considering the notes below), and yes, please!

> -Used by various scripts to generate some files included in SVN (mainly
> +Used by various scripts to generate some files included in Git (mainly

Do you think we could say "in our repository"?

> -files are not included in the SVN repository.  They are included in
> +files are not included in the Git repository.  They are included in

...in our repository...?

> -generated output files are not included in the SVN repository.  They are
> +generated output files are not included in the Git repository.  They are

Same here?

Thank you,
Gerald
Martin Jambor Jan. 16, 2020, 11:06 a.m. UTC | #2 
Hi,

On Thu, Jan 16 2020, Gerald Pfeifer wrote:
> On Wed, 15 Jan 2020, Martin Jambor wrote:
>> when going over stuff linked from the SummerOfCode wiki page, 
>> I found out that doc/install.texi still refers to Subversion.
>
> We've got a fair number of references left in various places;
> working through that slowly and appreciate your help!
>
>> The following patch replaces SVN to Git almost mechanically.
>
> I'm wondering whether we can/should see where to use a more
> generic term in a few cases; let me propose some such cases.
>
>> OK for trunk? And then perhaps for the opened release branches too?
>
> Yes (considering the notes below), and yes, please!

It was brought to my attention that there already is Eric's
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00719.html which addresses
the same thing and better, so I don't plan to commit my patch any more.

However, it would be great if the (already approved?) patch would be
comitted soon.

Thanks,

Martin
diff mbox series

Patch

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fc25469452c..18f73d5c394 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@ 
+2020-01-15  Martin Jambor  <mjambor@suse.cz>
+
+	* doc/install.texi (Prerequisites): Replace references to SVN with
+	references to Git.
+	(Downloading the source): Likewise.
+	(Configuration): Likewise.
+	(Building): Likewise.
+
 2020-01-13  Martin Liska  <mliska@suse.cz>
 
 	* opts.c (print_help): Do not print CL_PARAM
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index e62b3dae545..1a62cee2ab5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -356,7 +356,7 @@  and up works.
 Necessary when regenerating @file{Makefile} dependencies in libiberty.
 Necessary when regenerating @file{libiberty/functions.texi}.
 Necessary when generating manpages from Texinfo manuals.
-Used by various scripts to generate some files included in SVN (mainly
+Used by various scripts to generate some files included in Git (mainly
 Unicode-related and rarely changing) from source tables.
 
 Used by @command{automake}.
@@ -482,7 +482,7 @@  Necessary to regenerate the top level @file{Makefile.in} file from
 Necessary when modifying @file{*.l} files.
 
 Necessary to build GCC during development because the generated output
-files are not included in the SVN repository.  They are included in
+files are not included in the Git repository.  They are included in
 releases.
 
 @item Texinfo version 4.7 (or later)
@@ -495,7 +495,7 @@  create printable documentation in DVI or PDF format.  Texinfo version
 4.8 or later is required for @command{make pdf}.
 
 Necessary to build GCC documentation during development because the
-generated output files are not included in the SVN repository.  They are
+generated output files are not included in the Git repository.  They are
 included in releases.
 
 @item @TeX{} (any working version)
@@ -509,10 +509,10 @@  DVI or PDF files, respectively.
 Necessary to regenerate @file{jit/docs/_build/texinfo} from the @file{.rst}
 files in the directories below @file{jit/docs}.
 
-@item SVN (any version)
+@item Git (any version)
 @itemx SSH (any version)
 
-Necessary to access the SVN repository.  Public releases and weekly
+Necessary to access the Git repository.  Public releases and weekly
 snapshots of the development sources are also available via HTTPS@.
 
 @item GNU diffutils version 2.7 (or later)
@@ -547,7 +547,7 @@  own sources.
 @cindex Downloading GCC
 @cindex Downloading the Source
 
-GCC is distributed via @uref{http://gcc.gnu.org/svn.html,,SVN} and via
+GCC is distributed via @uref{https://gcc.gnu.org/git.html,,Git} and via
 HTTPS as tarballs compressed with @command{gzip} or @command{bzip2}.
 
 Please refer to the @uref{http://gcc.gnu.org/releases.html,,releases web page}
@@ -606,7 +606,7 @@  for both native and cross targets.
 We use @var{srcdir} to refer to the toplevel source directory for
 GCC; we use @var{objdir} to refer to the toplevel build/object directory.
 
-If you obtained the sources via SVN, @var{srcdir} must refer to the top
+If you obtained the sources via Git, @var{srcdir} must refer to the top
 @file{gcc} directory, the one where the @file{MAINTAINERS} file can be
 found, and not its @file{gcc} subdirectory, otherwise the build will fail.
 
@@ -1543,7 +1543,7 @@  with @option{--enable-bootstrap}.
 @item --enable-generated-files-in-srcdir
 Neither the .c and .h files that are generated from Bison and flex nor the
 info manuals and man pages that are built from the .texi files are present
-in the SVN development tree.  When building GCC from that development tree,
+in the Git development tree.  When building GCC from that development tree,
 or from one of our snapshots, those generated files are placed in your
 build directory, which allows for the source to be in a readonly
 directory.
@@ -1843,7 +1843,7 @@  consistency checks of the requested complexity.  This does not change the
 generated code, but adds error checking within the compiler.  This will
 slow down the compiler and may only work properly if you are building
 the compiler with GCC@.  This is @samp{yes,extra} by default when building
-from SVN or snapshots, but @samp{release} for releases.  The default
+from Git or snapshots, but @samp{release} for releases.  The default
 for building the stage1 compiler is @samp{yes}.  More control
 over the checks may be had by specifying @var{list}.  The categories of
 checks available are @samp{yes} (most common checks
@@ -2495,7 +2495,7 @@  that type mismatches occur, this could be the cause.
 
 The solution is not to use such a directory for building GCC@.
 
-Similarly, when building from SVN or snapshots, or if you modify
+Similarly, when building from Git or snapshots, or if you modify
 @file{*.l} files, you need the Flex lexical analyzer generator
 installed.  If you do not modify @file{*.l} files, releases contain
 the Flex-generated files and you do not need Flex installed to build
@@ -2503,7 +2503,7 @@  them.  There is still one Flex-based lexical analyzer (part of the
 build machinery, not of GCC itself) that is used even if you only
 build the C front end.
 
-When building from SVN or snapshots, or if you modify Texinfo
+When building from Git or snapshots, or if you modify Texinfo
 documentation, you need version 4.7 or later of Texinfo installed if you
 want Info documentation to be regenerated.  Releases contain Info
 documentation pre-built for the unmodified documentation in the release.