This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal for the transition timetable for the move to GIT


On Mon, 16 Dec 2019, Segher Boessenkool wrote:

> And the current mirror is "right", already, as Jeff said at the Cauldron
> (a minute before we unanymously decided to do the conversion soon; this
> is over three months ago already).

All the discussion at the Cauldron tells us is many people like the idea 
of moving to git and it not taking forever.  Inviting a crowd to agree 
with a proposition is not a useful way to judge the technical merits of 
any particular detailed conversion approach.

> > That missing branches 
> > in Maxim's conversion could be noted only today clearly shows that 
> 
> ... clearly shows that *no one cares* about those branches.

Since Maxim said that all branches were present, that indicates a lack of 
validation, and a lack of validation by other people since then.  Checking 
the set of branches and tags present is one of the most basic checks on a 
conversion to identify problems.

> > I believe it's at least as ready as Maxim's.
> 
> I do not agree.  You say the reposurgeon conversion is not ready today.
> Maxim's conversion has been ready for many months.

I believe it's ready in the form of source code (gcc-conversion repository 
and newsvn3 branch in the reposurgeon repository).  I'm running a test 
conversion to check this and produce the binary form (converted git 
repository); conversions just take a while to run.  With correctness 
issues having been addressed, we're working on performance issues, and I'm 
running a second test conversion on a second machine with both a patch 
I've just written that passes reposurgeon's tests and I hope will save 
about 8 hours on the conversion time, and further performance improvements 
that went in overnight that should save some more hours via saving memory 
usage.  (A significant proportion of the time for a conversion is spent by 
git-fast-import reading the fast-import stream, which places a lower bound 
of a few hours on the time taken for a conversion even if everything 
outside of git is infinitely fast.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]