This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: The far past of GCC
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "Eric S. Raymond" <esr at thyrsus dot com>, <gcc at gcc dot gnu dot org>
- Date: Sun, 29 Dec 2019 22:38:56 +0000
- Subject: Re: The far past of GCC
- Ironport-sdr: oXxzYRhIZ0mr54uiMeWZGUpzNv2k4g5uvmWQhXqbgpfj4FesqU3GBFj+PQGMWg7Hgu7d+adjVo /AwoxMPke7pF8+tBQIMRyTU5WNT2yj/uggX2AbL5EhksyZjLxKWvlFtUEbEehFt8hYXeUJkLqq lKCh5myhe6SyiAnm/zbZjF8PFF7fVaXVLvDdZoo/CzE4+kW+pr1YKb025u9K6FNsU3PAySpDnc GiVw9PknDpBm/KoH5//Ah6drFXOI/smqZNbTR6mQJuCjNDuYG4Suspm259U2RJiZpLY4VF+0OD 6Vs=
- Ironport-sdr: Sbr6gMklXPR/tld/xi+Cx9eSMO1LO6EuR8qMtSuAsccZmV+rZHVcVJ8+DdqFvcx8zout7piwgT rxQpugq21zhuTNVdtUjD236JCLAHW6/IEpdZ03BdORGKSGLHD8XHD+QvAby9mHbZV+MJT3uC29 Of632pi3ivABCwJmTtWI9cKFw/L5ajG6+Eo2Dze3DCeDdjKqVHFIXBKIumS046ZwKPOhjI6lNA wO0EBXCTyp0X7QwSieqndQjOXdxlP/sc7r37It92bbQ6pG20PnTUliCEfGSIvxs8I83U0/dOPk 6m8=
- References: <20191228085310.B665F4704C53@snark.thyrsus.com> <60ca7d2f39e3ab56b670fd30211fdc61e44df488.camel@redhat.com>
On Sat, 28 Dec 2019, Jeff Law wrote:
> I believe RCS was initially used circa 1992 on the FSF machine which
> held the canonical GCC sources. But I'm not aware of anyone still
> having a copy of the old RCS ,v files.
See ftp://gcc.gnu.org/pub/gcc/old-releases/old-cvs/ for the old repository
(that started out as a set of RCS ,v files). (Or rsync the GCC CVS
repository from sourceware, and the old-gcc subdirectory is a copy of that
repository.)
The key issue with integrating tarballs into a git repository is that many
files (in particular documentation and ChangeLogs) were, for a long time,
not version-controlled in gcc2. So you have the version of the history in
SVN (detailed at the revision level but not covering all files) and the
version from tarballs / diffs (having all files but not detailed at the
revision level).
Trying to integrate tarballs into the middle of the sequence not covering
all files leads either the documentation files appearing or disappearing,
or to intermediate revisions having non-matching versions of those files.
To avoid that, I think a natural representation in git might be: we have
master, with the history as it is in SVN, and a separate branch whose tree
contents and first-parent ancestry come from the tarballs (from 0.9
through to 2.7.2.3), leading back to an orphan commit for gcc-0.9. Then,
releases in that sequence that we can identify a corresponding master
commit for can have the commit adding tarball contents set up as a merge
commit, with the second parent being the corresponding master commit.
(Actually there might be more than one such branch, reflecting the time
GCC 1 releases were maintained while GCC 2 development was underway.)
A key feature of doing things like that is that it does *not* need to be
done at the same time as the main git conversion, because the tarballs
don't become part of the git ancestry of any commit now in SVN; their
contents (and corresponding release tags) can be added to git later once
ready.
--
Joseph S. Myers
joseph@codesourcery.com