Re: Goals for repo conversion day

[Eli Zaretskii]

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

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.

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

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

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

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

Why is that a problem?

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

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

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.

So with all due respect, I question the need for this elaborate work,
especially since you evidently know very little about the VCS related
practices around here, certainly during the bzr age.

Comments and opinions by others are welcome.