New review conversion of Emacs repository

New review conversion of Emacs repository

[Eric S. Raymond]

Next review version of the repository conversion is here:

	git://gitorious.org/emacs-transition/review6.git

This one is current to complete to 2014-09-11 12:44:25 -0700.
It has been repacked.

Cloning this may appear at first sight to fetch only the master branch,
but do "git branch -a" to list the other remote branches.  You can
easily create local tracking branches for those you are interested in.

The conversion machinery, including the lift script, can be cloned from

	git://gitorious.org/emacs-transition/emacs-transition.git

How you can help:

1. Report Bazaar and CVS references that aren't already in the
emacs.lift file (see BAZAAR REFERENCES and CVS REFERENCES). 

2. Check the CVS references already in emacs.lift (see CVS REFERENCES). 

3. Check bzr references translated with nochecklog, nocheckcomment,
everylog, and everycomment. (The changelog and changecomment commands
do not need to be checked by hand as they are automatically verified
by a script in the conversion machinery.)

4. Use gitk or git log to spot CVS cliques consisting of uncoalesced
single-file changes and their ChangeLog entry commits; report them so
I can squash them into proper changesets. 

5. Investigate the old-branches and other-branches groups and determine
which branches, if any, should be discarded.

6. (Advanced) Identify the actual deletion points of as many of the
=-prefixed attic files as possible.  Look for the string "ATTIC
FILES" in emacs.lift and try to turn 'attic' calls into 'deattic'
calls. (I've already done this, but it's a difficult and finicky process;
I might have missed some.)

7. (Advanced) Learn the reposurgeon DSL.  Use this knowledge to audit
emacs.lift for correctness.

Barring any glitches found by people (other than me) doing these
auditing steps, the conversion procedure is pretty much ready to go.
I rerun it occasionally to catch new bzr references in the logs and
comments.  Note that a full conversion takes about eight hours of
commpute time; this constraint needs to be planned around in the 
conversion-day schedule.

Re: New review conversion of Emacs repository

[Paul Eggert]

Thanks for doing that.  As an example of how much faster 'git' is on my 
desktop, 'git log' takes 2 seconds, whereas 'bzr log' takes 28 seconds, 
with both repositories hot.  I am looking forward to the switchover.

I looked at the conversion and have some questions.  Sorry, it's been so 
long since I reviewed the last conversion that I forgot whether these 
issues have come up before.  (If they have, please just consider this as 
stuff that still worries me mildly. :-)

* On the master/trunk branch, the git repository contains 549 commits 
more than the bzr repository does, 117867 versus 117318.  I assume this 
is because the git repository lists each merged change separately rather 
than a single 'Merge from' commit.  I wanted to confirm this, though. 
For example, git commit 94075d6f559ced1fab36c50bdfa51a612f422080 by 
Glenn Morris <rgm@gnu.org> dated Sep 7 22:57:24 2014 -0700 isn't 
explictly mentioned in the bzr log, and was this because it was part of 
the bzr merge that produced trunk bzr 117839 dated 2014-09-07 23:00:58 
-0700 by Glenn?  Are there any other reasons a commit should appear in 
one log but not the other?

* Rewriting revision numbers occasionally makes ChangeLog lines longer 
than 80 characters.  I propose that we fix this via a manual pass after 
the change, something that's done fairly routinely for ChangeLog files 
anyway.

* This conversion treats ChangeLog as metadata, and I'd feel more 
comfortable if ChangeLog files were treated as data.  For example, if I 
ask the git repository "Please give me src/ChangeLog as the end of 
2012", I git a different answer than if I ask the bzr repository the 
same question.  (See the diff output below.)  I'd feel more comfortable 
if these changes were applied to the ChangeLog files via the 
abovementioned pass after the conversion, as that way the old git data 
will match the old bzr data exactly.

  $ diff -u <(cd trunk && bzr cat -r111390 ChangeLog) \
            <(cd review6 && git show \
                 431e43b612777eefb6655728f7979a9c8d87c429:ChangeLog)
  --- /dev/fd/63	2014-09-13 11:26:24.254835175 -0700
  +++ /dev/fd/62	2014-09-13 11:26:24.255835194 -0700
  @@ -1122,7 +1122,7 @@

   2012-06-23  Eli Zaretskii  <eliz@gnu.org>

  -	Fix the MS-Windows build broken by revno 108687.
  +	Fix the MS-Windows build broken by 
2012-06-22T21:17:42Z!eggert@cs.ucla.edu.
   	* lib/makefile.w32-in (GNULIBOBJS): Add $(BLD)/dtotimespec.$(O),
   	$(BLD)/gettime.$(O), $(BLD)/timespec-add.$(O), and
   	$(BLD)/timespec-sub.$(O).

Re: New review conversion of Emacs repository

[Eric S. Raymond]

Paul Eggert <eggert@cs.ucla.edu>:
> I looked at the conversion and have some questions.  Sorry, it's
> been so long since I reviewed the last conversion that I forgot
> whether these issues have come up before.  (If they have, please
> just consider this as stuff that still worries me mildly. :-)

These issues have not come up before.
 
> * On the master/trunk branch, the git repository contains 549
> commits more than the bzr repository does, 117867 versus 117318.  I
> assume this is because the git repository lists each merged change
> separately rather than a single 'Merge from' commit.  I wanted to
> confirm this, though. For example, git commit
> 94075d6f559ced1fab36c50bdfa51a612f422080 by Glenn Morris
> <rgm@gnu.org> dated Sep 7 22:57:24 2014 -0700 isn't explictly
> mentioned in the bzr log, and was this because it was part of the
> bzr merge that produced trunk bzr 117839 dated 2014-09-07 23:00:58
> -0700 by Glenn?  Are there any other reasons a commit should appear
> in one log but not the other?

I can't think of any other reason that the commit count on the git
side would be *greater*. Because of changeset coalescence in the CVS 
part of the history one would actually expect the commit count to drop.

In genersl bzr commits should go to git commits 1-1.

> * Rewriting revision numbers occasionally makes ChangeLog lines
> longer than 80 characters.  I propose that we fix this via a manual
> pass after the change, something that's done fairly routinely for
> ChangeLog files anyway.

Yes, I was planning to do this.

> * This conversion treats ChangeLog as metadata, and I'd feel more
> comfortable if ChangeLog files were treated as data.  For example,
> if I ask the git repository "Please give me src/ChangeLog as the end
> of 2012", I git a different answer than if I ask the bzr repository
> the same question.  (See the diff output below.)  I'd feel more
> comfortable if these changes were applied to the ChangeLog files via
> the abovementioned pass after the conversion, as that way the old
> git data will match the old bzr data exactly.

It's within the capability of my tools to do it either way.  The question
of how it should be done is really one about the philosophy of the conversion.
I see two possible positions:

Navigability first: Translate ChangeLog references so that after
the switchover they can all become (in effect) hotlinks, no matter
where they are in the history.

Reproducibility first: Don't translate, so old revisions have the same
ChangeLog comment they did formerly, but the commit references in them
can't in general be made to work as hotlinks.  (No, an index of bzr
revisions wouldn't be good enough to enable this; there are too many
strange mutant reference forms in there.  And CVS references.  And
plain old typos.)

I have so far chosen to put navigability first, because I think that
(1) one central purpose of the conversion is to make the modification
history of the code as easy as possible to explore, and (2) I don't
expect the old repository to entirely vanish; it will still be around as
an archive for those who value bit-for-bit fidelity of the old ChangeLogs.

There is, of course, a case for going in the opposite direction as you
suggest.  It's a policy rather than technical decision, so I would
prefer to get some sense of what the whole dev group wants rather than
either you or me deciding on our own hook. In the absence of a strong
consensus on the matter I guess it would be up to Stefan to decide.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

New review conversion of Emacs repository

[Eric S. Raymond]

Next review version of the repository conversion is here:

	git://gitorious.org/emacs-transition/review7.git

This one is current to complete to 2014-10-30 05:23:43 -0400 and includes the transition patch.
It has been repacked.

Cloning this may appear at first sight to fetch only the master branch,
but do "git branch -a" to list the other remote branches.  You can
easily create local tracking branches for those you are interested in.

The conversion machinery, including the lift script, can be cloned from

	git://gitorious.org/emacs-transition/emacs-transition.git

How you can help:

1. Examine the transition  patch (last commit) for errors and problems.

2. Use gitk or git log to spot CVS cliques consisting of uncoalesced
single-file changes and their ChangeLog entry commits; report them so
I can squash them into proper changesets. 

3. Investigate the old-branches and other-branches groups and determine
which branches, if any, should be discarded.

4. (Advanced) Identify the actual deletion points of as many of the
=-prefixed attic files as possible.  Look for the string "ATTIC
FILES" in emacs.lift and try to turn 'attic' calls into 'deattic'
calls. (I've already done this, but it's a difficult and finicky process;
I might have missed some.)

5. (Advanced) Learn the reposurgeon DSL.  Use this knowledge to audit
emacs.lift for correctness.

Barring any glitches found by people (other than me) doing these
auditing steps, the conversion procedure is pretty much ready to go.
I rerun it occasionally to catch new bzr references in the logs and
comments.  Note that a full conversion takes about ten hours of
compute time; this constraint needs to be planned around in the 
conversion-day schedule.