This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Offer of help with move to git
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Eric S. Raymond" <esr at thyrsus dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 24 Aug 2015 14:21:34 +0000
- Subject: Re: Offer of help with move to git
- Authentication-results: sourceware.org; auth=none
- References: <20150823144340 dot GA7448 at thyrsus dot com>
On Sun, 23 Aug 2015, Eric S. Raymond wrote:
> Whoever you designate to lead the conversion *should read this
Jason Merrill <jason@redhat.com> is leading the conversion.
> Hwew's a particular warning: though you may be using git-svn for live
> gatewaying, it is *not* the way to go for full-history conversions, as
> it is likely to screw up the history in ways that are not apparent
> from merely looking at the head revision. The dump analyzer in my
> reposurgeon tool does a substantially better job.
Hence my suggestion in <https://gcc.gnu.org/ml/gcc/2015-08/msg00150.html>
of reconverting and then combining with the existing git-svn history via
renaming all the refs in the existing git repository, so as to preserve
the validity of commit references and git-only branches there while having
the main copy of the history properly converted.
There are definitely oddities from git-svn not knowing exactly which
subdirectories of /branches are themselves branches, and which are
containers for multiple branches (something that will need configuring
correctly for the proper conversion - I think it should be possible to
tell in a fairly automated way, e.g. if the directory contains ChangeLog
it's almost certainly a branch and if it doesn't it's probably a container
for branches but should be checked manually to make sure).
I don't know what either git-svn or reposurgeon make of the times when
trunk was accidentally deleted and then recreated as an SVN copy of a
pre-deletion revision (what we want to avoid for the proper conversion is
those looking like deletion and recreation of all files in trunk - commits
that don't change the tree at all, or complete omission of the deletion
and subsequent recreation, would be fine).
> pretty bulletproof. Problems are most likely if the SVN repo was
> previously converted from CVS, a process which in the past tended
It was converted from CVS. More precisely, from two CVS repositories: the
gcc2 repository (1988-1999, starting as a collection of RCS files and with
not many files version controlled before 1992 and documentation not
version controlled for years after then), and what started as the EGCS
repository (1997-2005). The two repositories were combined by a custom
version of CVS (work done by Ian Taylor) to produce the input to cvs2svn.
gcc2 changes between the start of EGCS in 1997 and 1999 when development
in the gcc2 project ended were moved to /branches/premerge-fsf-branch as
part of the combination process (pre-EGCS gcc2 changes are on trunk).
A few branches in the repository that started as the EGCS repository, the
history of which branches was particularly messed up by rebasing (branch
tags having been moved from one revision to another, leaving behind
unnamed branches), were deliberately omitted from the conversion to SVN to
avoid it generating large amounts of very messy and not particularly
useful history in the resulting repository.
--
Joseph S. Myers
joseph@codesourcery.com