Re: Goals for repo conversion day

["Eric S. Raymond" <esr@thyrsus.com>]

Eli Zaretskii <eliz@gnu.org>:
> > Date: Sat, 25 Jan 2014 09:06:38 -0500
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > Cc: schwab@linux-m68k.org, emacs-devel@gnu.org
> > 
> > 1. Unlifted Bazaar and CVS commit references.
> 
> A mapping file would be more than appropriate for that.  The number of
> references is below 200, which is small.  This was suggested already,
> and I don't think anyone objected vociferously enough for us to
> consider that as a non-option.

*I* object to this.  On the grounds that I've been through this dance
many times before, and know that such out-of-band representations
generally cost more hassle and deliver less than people expect when
they think them up.
 
> And, btw, I'm still not sure you have uncovered all of those
> references, since the numbers you posted were significantly smaller
> than what I get using simple bzr commands.  So it could be that you
> will be investing a non-trivial effort to do a partial job.

I'm not yet certain I have all the CVS references, but I'm pretty sure
I have all the Bazaar ones now. Your last feedback led me to improve
my search scripts.  I'll do another pass before I'm finished.

> > 2. CVS commit cliques that should have been coalesced but were not,
> >    probably because the time window was defaulted too small when parsecvs
> >    was run.  (Very often these seem to be a pairs of a change and its
> >    ChangeLog description with an empty comment.)
> 
> I'd say leave that alone.  When Emacs used CVS, it was customary to
> commit each file as a separate CVS command (RMS actually asked for
> that), and moreover, have the ChangeLog be committed once for several
> unrelated changes in the same directory.  So you will be unable to fix
> this without a lot of manual work, and for what? we've been living
> with this in bzr for several years, with no one complaining.

Much less manual work than you think.  Reposurgeon was designed with
this kind of fixup in mind.  While it does take some human judgment
to apply the tool properly, the process does not involve grovelling
through every commit by hand.  It's a tolerable amount of effort
even for a repository this large - and if it weren't, I'd add 
capability to reposurgeon until it became so.

As for nobody complaining...this is because your standards are low,
and your standards are low because the tools historically used for these
conversions were mostly shoddy and badly designed. Windows users don't 
complain about Notepad, either, because they don't know any better -
but that doesn't make Emacs a waste of time.

> > 3. Multiple roots.  Two of the multiples are emacs and elpa, but others 
> >    are junk lost+found branches which should be carefully inspected and
> >    then (probably) removed.
> 
> Leave them alone, they don't bother anyone.  Removal can be deferred
> for later, if we ever feel it to be necessary.

See "low standards", above.

> > 4. Obsolete tags (very minor problem, unlike the previous three easily
> >    fixed in git itself, but I might as well do it while larger cleanups
> >    are in progress).
> 
> Since this is minor, it isn't not worth the trouble, IMO.

By itself, no, it wouldn't be.

> > 5. Unconverted .bzrignores (and possibly .cvsignores) in the history.
> 
> Why is that a problem?

See "seamless history browsing".
 
> > Andreas is not to blame for these problems; the tools available to him
> > were deficient in a number of respects (I had not yet written reposurgeon at
> > the time of the move to Bazaar). These are all normal issues
> > which I've seen before in over a dozen large conversions.  
> 
> The repository converted by Andreas has one significant advantage: it
> is being actively used for many months.  Personally, I trust that more
> than any fancy new conversions, especially if we have to switch to git
> without a prolonged interregnum, during which both bzr and git are
> used (which is probably highly undesirable, if even possible).

You appear to have forgotten some important aspects of the plan I
posted.  Andreas's work isn't going to be thrown away, and there isn't
going to be any lengthy interregnum.

The way this is working is that I am building a reposurgeon script that
expresses a sequence of edits to Andreas's mirror. On conversion day 
we will apply that script once, after which everyone can re-clone and
go on as before.

> Noble goals all of them, but I'm skeptical as to whether they can be
> achieved in practice.  What's worse, we won't know whether some issues
> remained until much later.

I know they can be achieved in practice because I have achieved them before,
many times.  Most recently in the conversion of the groff history, but
you could check with the maintainers of NUT or Hercules or robotfindskitten
or Roundup as well. Or the Blender Foundation - blender is a big reposurgeon
conversion done by someone else.

If we find any problems afterwards, I have the tools to fix them. Part of
my commitment is to do that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>