Re: Goals for repo conversion day

[Eli Zaretskii]

> Date: Sat, 25 Jan 2014 11:01:24 -0500
> From: "Eric S. Raymond" <address@hidden>
> Cc: address@hidden, address@hidden
> 
> Eli Zaretskii <address@hidden>:
> > > Date: Sat, 25 Jan 2014 09:06:38 -0500
> > > From: "Eric S. Raymond" <address@hidden>
> > > Cc: address@hidden, address@hidden
> > > 
> > > 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.

With all due respect, this is not necessarily good enough.  You have
come to the project offering help, but no one gave you the right to
make unilateral decisions about these issues.  It won't be you who
will need to use this data in the years to come.  And whatever the
other projects which you converted in the past, I doubt that any of
them had as long and complex history as Emacs.

> > 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.

I'd appreciate if you posted the final list of the references, when
you are finished with it, so we could have some QA.

> > > 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.

The problem is not the size of the repository alone.  The problem is
that different portions of a single changeset were committed many
revisions apart.  And I don't even understand (and you didn't explain)
how will you handle the situation I described above, where a single
commit checked in ChangeLog changes for several unrelated commits in
the same directory.  Which commit clique will you assign the ChangeLog
commit to?  The devil is in the details, but you haven't provided any
details about your plans in this matter.  Would you please do that?

> 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.

Let's agree to keep such low-blow arguments out of this discussion.
They aren't fair, and aren't constructive.  Let's instead assume that
each side knows what they are doing and what they are talking about.

> > > 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.

See my response above.

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

Sorry, I don't understand.  Please elaborate: what is the relation
between these ignore files and history browsing?

> > 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.

Sorry, I don't see how this changes anything.  You are still going to
make deep changes to the existing mirror.

> > 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.

Sorry, been there done that.  The CVS to bzr conversion also seemed
flawless until much later.

> If we find any problems afterwards, I have the tools to fix them. Part of
> my commitment is to do that.

I don't think any of us can in good faith give such promises.