Goals for repo conversion day

[Eric S. Raymond]

Eli Zaretskii <address@hidden>:
> I actually don't understand why you are doing a separate new
> conversion, instead of relying on what Andreas already did.  AFAIR,
> there was no serious discussions of this, and certainly no decision
> (except, perhaps, by you).

I am in fact relying on what Andreas already did, not re-lifting the
CVS or Bazaar histories.  But it has some significant problems:

1. Unlifted Bazaar and CVS commit references.

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

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.

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

5. Unconverted .bzrignores (and possibly .cvsignores) in the history.

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.  

But I want Emacs to have a really high-quality conversion. It is a project
for the ages, one of the great artifacts of hacker culture, and I feel the
history deserves the kind of careful cleaning and restoration one would
give to an Old Master painting.

My quality goals for it include:

(a) Seamless history browsing.  A person looking at the development of
the code should not be distracted by artifacts of VCS changes.  This
means clean, properly unified changesets all the way back, properly
converted ignore files all the way back, and commit references that
are not just opaque cookies left over from previous VCSes.

(b) Information preservation for any future move to another VCS. The
main implication of this goal is not replacing fossil references with
git hashes, as these would present the same problems then that Bazaar
references do now.

(c) Cryptosigning so that future release integrity is protected and
historical release reconstructions can be trusted (that is, assuming
we don't believe the code history has already been corrupted).

(d) Avoidance of metadata representations that are easily stripped or
scrambled if someone gets momentarily forgetful in the future.  This
is why I don't want to rely on lightweight tags or git notes.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>