Repo cpnversion progress report

Repo cpnversion progress report

[Eric S. Raymond]

The current version of the reposurgeon conversion script follows.  The
header comment explains the major steps.  Most can be sanity-checked 
by eyeball and a little investigation with git log or gitk; interested
parties are invited to do so. 

If I'm missing any steps, tell me about it.

# Lift specification for the Emacs conversion
#
# Does the following steps: 
#
# 1. Delete junk lost+found branches
#
# 2. Map some remnant CVS user names to DVCS IDs
#
# 3. Delete most junk tags. A few will need to be removed by hand after the
#    fact in the live git repo because reposurgeon can't do it safely. (This
#    happens when the branch tip commit does not have a unique successor branch.)
#
# 4. Rename some branches that are in the remotes namespace despite 
#    having been merged long since.
#
# 5. Delete the elpa branch.
#
# 6. Turn most fossil Bazaar and CVS references into action stamps.  It's 
#    OK if this list isn't quite complete yet, mapping most references will
#    make the remaining ones stand out so this script can be corrected.  
#
# 7. Identify and convert .cvsignore and .bzrignore files.
#
# Not yet done:
#
# * Rename and deletion fixups for RCS attic files
#
# * Incorporate fixes-bug properties from Bazaar.
#
# * Squash commit cliques that were not properly merged during the
#   CVS lift.
#
# * Massage bug URLs in change comments into a canonical form.
#

############################################################################
#
# Remove junk lost+found branches.  These contain only dummy commits,
# apparently written as tests.
#
branch refs/tags/lost+found/12d398afa4d2b77d606b28fe43a2e5200c863419 delete
branch refs/tags/lost+found/5cf718038f760d6dc2e21dee3ce98061a975488a delete
branch refs/tags/lost+found/9a1501510c2a842e8597d695fec05563161a84b7 delete
branch refs/tags/lost+found/d4cd8d7c34cc79dc4abd0fec33cec74afa33e2d0 delete
branch refs/tags/lost+found/e387e14faeea08877c99ddf798d5a4c9f7999c72 delete
branch refs/tags/lost+found/b2e45f822e55882dda1bb80ca8b845d062d6d523 delete
branch refs/tags/lost+found/c003b5d7e29f2b7c3c340d4aa851a61cfa481ec8 delete
#
# Fix up some CVS usernames that apparently didn't get converted during
# the CVS lift. 
#
authors read <<EOF
thomas = Thomas Bushnell <thomas@gnu.ai.mit.edu>
monnier = Stefan Monnier <monnier@iro.umontreal.ca>
EOF
#
# Tag cleanup.
#
# All the Emacs tags are lightweight, hence the macro. 
# Tag deletions commented out with ## need to be done in git because
# their tip commits don't have unique successor branches. This
# exposes an underspecification hole reposurgeon won't go near.
#
define tagdelete tag tags/{0} delete
define tagrename tag tags/{0} rename tags/{1}
do tagdelete 0.1
##do tagdelete Boehm-GC-base
##do tagdelete CEDET_BASE
do tagrename EMACS_19_34 emacs-19.34
do tagrename EMACS_20_1 emacs-20.1
do tagrename EMACS_20_2 emacs-20.2
do tagrename EMACS_20_3 emacs-20.3
do tagrename EMACS_20_4 emacs-20.4
do tagrename EMACS_21_1 emacs-21.1
##do tagdelete EMACS_21_1_BASE
do tagrename EMACS_21_2 emacs-21.2
do tagrename EMACS_21_3 emacs-21.3
do tagrename EMACS_22_1 emacs-22.1
do tagrename EMACS_22_2 emacs-22.2
do tagrename EMACS_22_3 emacs-22.3
##do tagdelete EMACS_22_BRANCHPOINT
do tagrename EMACS_23_1 emacs-23.1
##do tagdelete EMACS_23_1_BASE
do tagrename EMACS_23_2 emacs-23.2
do tagrename EMACS_23_3 emacs-23.3
do tagrename EMACS_23_4 emacs-23.4
do tagrename EMACS_PRETEST_21_0_100 emacs-pretest-21.0.100
do tagrename EMACS_PRETEST_21_0_101 emacs-pretest-21.0.101
do tagrename EMACS_PRETEST_21_0_102 emacs-pretest-21.0.102
do tagrename EMACS_PRETEST_21_0_103 emacs-pretest-21.0.103
do tagrename EMACS_PRETEST_21_0_104 emacs-pretest-21.0.104
do tagrename EMACS_PRETEST_21_0_105 emacs-pretest-21.0.105
do tagrename EMACS_PRETEST_21_0_106 emacs-pretest-21.0.106
do tagrename EMACS_PRETEST_21_0_90 emacs-pretest-21.0.90
do tagrename EMACS_PRETEST_21_0_91 emacs-pretest-21.0.91
do tagrename EMACS_PRETEST_21_0_92 emacs-pretest-21.0.92
do tagrename EMACS_PRETEST_21_0_93 emacs-pretest-21.0.93
do tagrename EMACS_PRETEST_21_0_95 emacs-pretest-21.0.95
do tagrename EMACS_PRETEST_21_0_96 emacs-pretest-21.0.96
do tagrename EMACS_PRETEST_21_0_97 emacs-pretest-21.0.97
do tagrename EMACS_PRETEST_21_0_98 emacs-pretest-21.0.98
do tagrename EMACS_PRETEST_21_0_99 emacs-pretest-21.0.99
do tagrename EMACS_PRETEST_21_2_91 emacs-pretest-21.2.91
do tagrename EMACS_PRETEST_21_2_92 emacs-pretest-21.2.92
do tagrename EMACS_PRETEST_21_2_93 emacs-pretest-21.2.93
do tagrename EMACS_PRETEST_21_2_94 emacs-pretest-21.2.94
do tagrename EMACS_PRETEST_21_2_95 emacs-pretest-21.2.95
do tagrename EMACS_PRETEST_22_0_90 emacs-pretest-22.0.90
do tagrename EMACS_PRETEST_22_0_91 emacs-pretest-22.0.91
do tagrename EMACS_PRETEST_22_0_92 emacs-pretest-22.0.92
do tagrename EMACS_PRETEST_22_0_93 emacs-pretest-22.0.93
do tagrename EMACS_PRETEST_22_0_94 emacs-pretest-22.0.94
do tagrename EMACS_PRETEST_22_0_95 emacs-pretest-22.0.95
do tagrename EMACS_PRETEST_22_0_96 emacs-pretest-22.0.96
do tagrename EMACS_PRETEST_22_0_97 emacs-pretest-22.0.97
do tagrename EMACS_PRETEST_22_0_98 emacs-pretest-22.0.98
do tagrename EMACS_PRETEST_22_0_99 emacs-pretest-22.0.99
do tagrename EMACS_PRETEST_22_0_990 emacs-pretest-22.0.990
do tagrename EMACS_PRETEST_22_1_90 emacs-pretest-22.1.90
do tagrename EMACS_PRETEST_22_1_91 emacs-pretest-22.1.91
do tagrename EMACS_PRETEST_22_1_92 emacs-pretest-22.1.92
do tagrename EMACS_PRETEST_22_2_90 emacs-pretest-22.2.90
do tagrename EMACS_PRETEST_22_2_91 emacs-pretest-22.2.91
do tagrename EMACS_PRETEST_22_2_92 emacs-pretest-22.2.92
do tagrename EMACS_PRETEST_23_0_90 emacs-pretest-23.0.90
do tagrename EMACS_PRETEST_23_0_91 emacs-pretest-23.0.91
do tagrename EMACS_PRETEST_23_0_92 emacs-pretest-23.0.92
do tagrename EMACS_PRETEST_23_0_93 emacs-pretest-23.0.93
do tagrename EMACS_PRETEST_23_0_94 emacs-pretest-23.0.94
do tagrename EMACS_PRETEST_23_0_95 emacs-pretest-23.0.95
do tagrename EMACS_PRETEST_23_0_96 emacs-pretest-23.0.96
do tagrename EMACS_PRETEST_23_1_90 emacs-pretest-23.1.90
do tagrename EMACS_PRETEST_23_1_91 emacs-pretest-23.1.91
do tagrename EMACS_PRETEST_23_1_92 emacs-pretest-23.1.92
do tagrename EMACS_PRETEST_23_1_93 emacs-pretest-23.1.93
do tagrename EMACS_PRETEST_23_1_94 emacs-pretest-23.1.94
do tagrename EMACS_PRETEST_23_1_95 emacs-pretest-23.1.95
do tagrename EMACS_PRETEST_23_1_96 emacs-pretest-23.1.96
do tagrename EMACS_PRETEST_23_1_97 emacs-pretest-23.1.97
do tagrename EMACS_PRETEST_23_2_90 emacs-pretest-23.2.90
do tagrename EMACS_PRETEST_23_2_91 emacs-pretest-23.2.91
do tagrename EMACS_PRETEST_23_2_92 emacs-pretest-23.2.92
do tagrename EMACS_PRETEST_23_2_93 emacs-pretest-23.2.93
do tagrename EMACS_PRETEST_23_2_93_1 emacs-pretest-23.2.93.1
do tagrename EMACS_PRETEST_23_2_94 emacs-pretest-23.2.94
do tagrename EMACS_PRETEST_23_3_90 emacs-pretest-23.3.90
do tagrename EMACS_PRETEST_24_0_05 emacs-pretest-24.0.05
do tagrename EMACS_PRETEST_24_0_90 emacs-pretest-24.0.90
do tagrename EMACS_PRETEST_24_0_91 emacs-pretest-24.0.91
do tagrename EMACS_PRETEST_24_0_92 emacs-pretest-24.0.92
do tagrename EMACS_PRETEST_24_0_93 emacs-pretest-24.0.93
do tagrename EMACS_PRETEST_24_0_94 emacs-pretest-24.0.94
do tagrename EMACS_PRETEST_24_0_95 emacs-pretest-24.0.95
do tagdelete Ilya_4_23
do tagdelete Ilya_4_32
do tagdelete Ilya_4_35
do tagdelete Ilya_5_0
do tagdelete Ilya_5_10
do tagdelete Ilya_5_22
do tagdelete Ilya_5_23
do tagdelete Ilya_5_3
do tagdelete Ilya_5_7
##do tagdelete NewVC-fileset-BASE
##do tagdelete RMAIL-MBOX-BASE
do tagdelete Release_5_25
do tagdelete URL_2004-04-04_01h16
do tagdelete VENDOR-3_3
do tagdelete VENDOR-3_4
do tagdelete VENDOR-3_5
do tagdelete VENDOR-3_6
##do tagdelete XFT_JHD_BRANCH_base
do tagdelete after-merge-gnus-5_10
do tagdelete amigados-merge
do tagdelete before-merge-emacs-app-to-trunk
do tagdelete before-merge-gnus-5_10
do tagdelete before-merge-multi-tty-to-trunk
do tagdelete before-merge-unicode-to-trunk
do tagdelete before-miles-orphaned-changes
do tagdelete before-remove-carbon
do tagdelete before-remove-vms
do tagdelete before-thomas-posix1996
##do tagdelete branchpoint-5_8
##do tagdelete custom_themes_branchpoint
# keep emacs-19.34
# keep emacs-20.1
# keep emacs-20.2
# keep emacs-20.3
# keep emacs-20.4
# keep emacs-21.1
# keep emacs-21.2
# keep emacs-21.3
# keep emacs-22.1
# keep emacs-22.2
# keep emacs-22.3
# keep emacs-23.1
# keep emacs-23.2
# keep emacs-23.3
# keep emacs-23.4
do tagdelete emacs-23/emacs-23.2
# keep emacs-24.0.96
# keep emacs-24.0.97
# keep emacs-24.1
# keep emacs-24.2
# keep emacs-24.2.90
# keep emacs-24.2.91
# keep emacs-24.2.92
# keep emacs-24.2.93
# keep emacs-24.3
##do tagdelete emacs-24.3-base
# keep emacs-24.3-rc1
##do tagdelete emacs-bidi-base
##do tagdelete emacs-unicode-2-base
do tagdelete emacs-unicode-2-pre-sync
##do tagdelete emacs-unicode-base
##do tagdelete font-backend-base
do tagdelete gcc-2_8_1-980401
do tagdelete gcc-2_8_1-980402
do tagdelete gcc-2_8_1-980407
do tagdelete gcc-2_8_1-980412
do tagdelete gcc-2_8_1-980413
do tagdelete gcc-2_8_1-980419
do tagdelete gcc-2_8_1-980426
do tagdelete gcc-2_8_1-980502
do tagdelete gcc-2_8_1-980513
do tagdelete gcc-2_8_1-980525
do tagdelete gcc-2_8_1-980529
do tagdelete gcc-2_8_1-980608
do tagdelete gcc-2_8_1-980609
do tagdelete gcc-2_8_1-980627
do tagdelete gcc-2_8_1-980705
do tagdelete gcc-2_8_1-980718
do tagdelete gcc-2_8_1-980811
do tagdelete gcc-2_8_1-980813
do tagdelete gcc-2_8_1-980928
do tagdelete gcc-2_8_1-980929
do tagdelete gcc-2_8_1-RELEASE
do tagdelete gcc_2_8_1-980315
do tagdelete gcc_2_8_1-980929
do tagdelete glibc-2_0_2
do tagdelete glibc-2_0_4
do tagdelete gnumach-release-1-1
do tagdelete gnumach-release-1-1-1
do tagdelete gnumach-release-1-1-2
do tagdelete gnumach-release-1-1-3
do tagdelete gnus-5_10-branchpoint
do tagdelete gnus-5_10-post-merge-josefsson
do tagdelete gnus-5_10-post-merge-yamaoka
do tagdelete gnus-5_10-pre-merge-josefsson
do tagdelete gnus-5_10-pre-merge-yamaoka
do tagdelete handa-temp-tag
do tagdelete hurd-release-0-2
do tagdelete jimb-sync-Nov-3-1992
do tagdelete kfs_20030524_post
do tagdelete kfs_20030524_pre
##do tagdelete lexbind-base
do tagdelete libc-1-90
do tagdelete libc-1-91
do tagdelete libc-1-92
do tagdelete libc-1-93
do tagdelete libc-950402
do tagdelete libc-950411
do tagdelete libc-950722
do tagdelete libc-950723
do tagdelete libc-950922
do tagdelete libc-951016
do tagdelete libc-951018
do tagdelete libc-951029
do tagdelete libc-951031
do tagdelete libc-951101
do tagdelete libc-951102
do tagdelete libc-951103
do tagdelete libc-951104
do tagdelete libc-951105
do tagdelete libc-951106
do tagdelete libc-951107
do tagdelete libc-951108
do tagdelete libc-951109
do tagdelete libc-951110
do tagdelete libc-951111
do tagdelete libc-951112
do tagdelete libc-951113
do tagdelete libc-951114
do tagdelete libc-951115
do tagdelete libc-951116
do tagdelete libc-951117
do tagdelete libc-951118
do tagdelete libc-951119
do tagdelete libc-951120
do tagdelete libc-951121
do tagdelete libc-951122
do tagdelete libc-951123
do tagdelete libc-951124
do tagdelete libc-951125
do tagdelete libc-951126
do tagdelete libc-951127
do tagdelete libc-951128
do tagdelete libc-951129
do tagdelete libc-951130
do tagdelete libc-951201
do tagdelete libc-951202
do tagdelete libc-951203
do tagdelete libc-951204
do tagdelete libc-951206
do tagdelete libc-951208
do tagdelete libc-951209
do tagdelete libc-951210
do tagdelete libc-951211
do tagdelete libc-951212
do tagdelete libc-951213
do tagdelete libc-951214
do tagdelete libc-951215
do tagdelete libc-951216
do tagdelete libc-951217
do tagdelete libc-951218
do tagdelete libc-951219
do tagdelete libc-951220
do tagdelete libc-951221
do tagdelete libc-951222
do tagdelete libc-951223
do tagdelete libc-951224
do tagdelete libc-951225
do tagdelete libc-951226
do tagdelete libc-951227
do tagdelete libc-951228
do tagdelete libc-951229
do tagdelete libc-951230
do tagdelete libc-951231
do tagdelete libc-960101
do tagdelete libc-960102
do tagdelete libc-960103
do tagdelete libc-960104
do tagdelete libc-960105
do tagdelete libc-960106
do tagdelete libc-960107
do tagdelete libc-960108
do tagdelete libc-960109
do tagdelete libc-960110
do tagdelete libc-960111
do tagdelete libc-960112
do tagdelete libc-960113
do tagdelete libc-960114
do tagdelete libc-960115
do tagdelete libc-960116
do tagdelete libc-960117
do tagdelete libc-960118
do tagdelete libc-960119
do tagdelete libc-960120
do tagdelete libc-960121
do tagdelete libc-960122
do tagdelete libc-960123
do tagdelete libc-960124
do tagdelete libc-960125
do tagdelete libc-960126
do tagdelete libc-960127
do tagdelete libc-960128
do tagdelete libc-960129
do tagdelete libc-960130
do tagdelete libc-960131
do tagdelete libc-960201
do tagdelete libc-960202
do tagdelete libc-960203
do tagdelete libc-960204
do tagdelete libc-960205
do tagdelete libc-960206
do tagdelete libc-960207
do tagdelete libc-960208
do tagdelete libc-960209
do tagdelete libc-960210
do tagdelete libc-960211
do tagdelete libc-960212
do tagdelete libc-960213
do tagdelete libc-960214
do tagdelete libc-960215
do tagdelete libc-960216
do tagdelete libc-960217
do tagdelete libc-960218
do tagdelete libc-960219
do tagdelete libc-960220
do tagdelete libc-960221
do tagdelete libc-960222
do tagdelete libc-960223
do tagdelete libc-960224
do tagdelete libc-960225
do tagdelete libc-960226
do tagdelete libc-960227
do tagdelete libc-960228
do tagdelete libc-960229
do tagdelete libc-960302
do tagdelete libc-960303
do tagdelete libc-960304
do tagdelete libc-960305
do tagdelete libc-960306
do tagdelete libc-960307
do tagdelete libc-960308
do tagdelete libc-960309
do tagdelete libc-960310
do tagdelete libc-960311
do tagdelete libc-960312
do tagdelete libc-960313
do tagdelete libc-960314
do tagdelete libc-960315
do tagdelete libc-960316
do tagdelete libc-960317
do tagdelete libc-960318
do tagdelete libc-960319
do tagdelete libc-960320
do tagdelete libc-960321
do tagdelete libc-960322
do tagdelete libc-960323
do tagdelete libc-960324
do tagdelete libc-960325
do tagdelete libc-960326
do tagdelete libc-960327
do tagdelete libc-960328
do tagdelete libc-960329
do tagdelete libc-960330
do tagdelete libc-960331
do tagdelete libc-960401
do tagdelete libc-960402
do tagdelete libc-960403
do tagdelete libc-960404
do tagdelete libc-960405
do tagdelete libc-960406
do tagdelete libc-960407
do tagdelete libc-960408
do tagdelete libc-960409
do tagdelete libc-960410
do tagdelete libc-960411
do tagdelete libc-960412
do tagdelete libc-960413
do tagdelete libc-960414
do tagdelete libc-960415
do tagdelete libc-960416
do tagdelete libc-960417
do tagdelete libc-960418
do tagdelete libc-960419
do tagdelete libc-960420
do tagdelete libc-960421
do tagdelete libc-960422
do tagdelete libc-960423
do tagdelete libc-960424
do tagdelete libc-960425
do tagdelete libc-960426
do tagdelete libc-960427
do tagdelete libc-960428
do tagdelete libc-960429
do tagdelete libc-960430
do tagdelete libc-960501
do tagdelete libc-960502
do tagdelete libc-960503
do tagdelete libc-960504
do tagdelete libc-960505
do tagdelete libc-960506
do tagdelete libc-960507
do tagdelete libc-960508
do tagdelete libc-960509
do tagdelete libc-960510
do tagdelete libc-960511
do tagdelete libc-960512
do tagdelete libc-960513
do tagdelete libc-960514
do tagdelete libc-960515
do tagdelete libc-960516
do tagdelete libc-960517
do tagdelete libc-960518
do tagdelete libc-960519
do tagdelete libc-960520
do tagdelete libc-960521
do tagdelete libc-960522
do tagdelete libc-960523
do tagdelete libc-960524
do tagdelete libc-960525
do tagdelete libc-960526
do tagdelete libc-960527
do tagdelete libc-960528
do tagdelete libc-960529
do tagdelete libc-960530
do tagdelete libc-960531
do tagdelete libc-960601
do tagdelete libc-960602
do tagdelete libc-960603
do tagdelete libc-960604
do tagdelete libc-960605
do tagdelete libc-960606
do tagdelete libc-960607
do tagdelete libc-960608
do tagdelete libc-960609
do tagdelete libc-960610
do tagdelete libc-960611
do tagdelete libc-960612
do tagdelete libc-960613
do tagdelete libc-960614
do tagdelete libc-960615
do tagdelete libc-960616
do tagdelete libc-960617
do tagdelete libc-960618
do tagdelete libc-960619
do tagdelete libc-960620
do tagdelete libc-960621
do tagdelete libc-960622
do tagdelete libc-960623
do tagdelete libc-960624
do tagdelete libc-960625
do tagdelete libc-960626
do tagdelete libc-960627
do tagdelete libc-960628
do tagdelete libc-960629
do tagdelete libc-960630
do tagdelete libc-960701
do tagdelete libc-960702
do tagdelete libc-960703
do tagdelete libc-960704
do tagdelete libc-960705
do tagdelete libc-960706
do tagdelete libc-960707
do tagdelete libc-960708
do tagdelete libc-960709
do tagdelete libc-960710
do tagdelete libc-960711
do tagdelete libc-960712
do tagdelete libc-960713
do tagdelete libc-960714
do tagdelete libc-960715
do tagdelete libc-960716
do tagdelete libc-960717
do tagdelete libc-960718
do tagdelete libc-960719
do tagdelete libc-960720
do tagdelete libc-960721
do tagdelete libc-960722
do tagdelete libc-960723
do tagdelete libc-960724
do tagdelete libc-960725
do tagdelete libc-960726
do tagdelete libc-960727
do tagdelete libc-960728
do tagdelete libc-960729
do tagdelete libc-960730
do tagdelete libc-960731
do tagdelete libc-960801
do tagdelete libc-960802
do tagdelete libc-960803
do tagdelete libc-960804
do tagdelete libc-960805
do tagdelete libc-960806
do tagdelete libc-960807
do tagdelete libc-960808
do tagdelete libc-960809
do tagdelete libc-960810
do tagdelete libc-960811
do tagdelete libc-960812
do tagdelete libc-960813
do tagdelete libc-960814
do tagdelete libc-960815
do tagdelete libc-960816
do tagdelete libc-960817
do tagdelete libc-960818
do tagdelete libc-960819
do tagdelete libc-960820
do tagdelete libc-960821
do tagdelete libc-960822
do tagdelete libc-960823
do tagdelete libc-960824
do tagdelete libc-960825
do tagdelete libc-960826
do tagdelete libc-960827
do tagdelete libc-960828
do tagdelete libc-960829
do tagdelete libc-960830
do tagdelete libc-960831
do tagdelete libc-960901
do tagdelete libc-960902
do tagdelete libc-960903
do tagdelete libc-960904
do tagdelete libc-960905
do tagdelete libc-960906
do tagdelete libc-960907
do tagdelete libc-960908
do tagdelete libc-960909
do tagdelete libc-960910
do tagdelete libc-960911
do tagdelete libc-960912
do tagdelete libc-960913
do tagdelete libc-960918
do tagdelete libc-960919
do tagdelete libc-960920
do tagdelete libc-960921
do tagdelete libc-960922
do tagdelete libc-960923
do tagdelete libc-960925
do tagdelete libc-960926
do tagdelete libc-960927
do tagdelete libc-960928
do tagdelete libc-960929
do tagdelete libc-961001
do tagdelete libc-961004
do tagdelete libc-961005
do tagdelete libc-961006
do tagdelete libc-961007
do tagdelete libc-961008
do tagdelete libc-961009
do tagdelete libc-961010
do tagdelete libc-961011
do tagdelete libc-961012
do tagdelete libc-961013
do tagdelete libc-961014
do tagdelete libc-961015
do tagdelete libc-961016
do tagdelete libc-961017
do tagdelete libc-961018
do tagdelete libc-961019
do tagdelete libc-961020
do tagdelete libc-961021
do tagdelete libc-961022
do tagdelete libc-961023
do tagdelete libc-961024
do tagdelete libc-961025
do tagdelete libc-961026
do tagdelete libc-961027
do tagdelete libc-961028
do tagdelete libc-961029
do tagdelete libc-961030
do tagdelete libc-961031
do tagdelete libc-961101
do tagdelete libc-961102
do tagdelete libc-961103
do tagdelete libc-961104
do tagdelete libc-961105
do tagdelete libc-961106
do tagdelete libc-961107
do tagdelete libc-961108
do tagdelete libc-961109
do tagdelete libc-961110
do tagdelete libc-961111
do tagdelete libc-961114
do tagdelete libc-961115
do tagdelete libc-961116
do tagdelete libc-961117
do tagdelete libc-961118
do tagdelete libc-961119
do tagdelete libc-961120
do tagdelete libc-961121
do tagdelete libc-961203
do tagdelete libc-961204
do tagdelete libc-961205
do tagdelete libc-961206
do tagdelete libc-961207
do tagdelete libc-961208
do tagdelete libc-961209
do tagdelete libc-961210
do tagdelete libc-961211
do tagdelete libc-961212
do tagdelete libc-961213
do tagdelete libc-961214
do tagdelete libc-961215
do tagdelete libc-961216
do tagdelete libc-961217
do tagdelete libc-961218
do tagdelete libc-961219
do tagdelete libc-961220
do tagdelete libc-961221
do tagdelete libc-961222
do tagdelete libc-961223
do tagdelete libc-961224
do tagdelete libc-961225
do tagdelete libc-961226
do tagdelete libc-961227
do tagdelete libc-961228
do tagdelete libc-961229
do tagdelete libc-961230
do tagdelete libc-961231
do tagdelete libc-970101
do tagdelete libc-970102
do tagdelete libc-970103
do tagdelete libc-970104
do tagdelete libc-970105
do tagdelete libc-970106
do tagdelete libc-970107
do tagdelete libc-970108
do tagdelete libc-970109
do tagdelete libc-970110
do tagdelete libc-970111
do tagdelete libc-970112
do tagdelete libc-970113
do tagdelete libc-970114
do tagdelete libc-970115
do tagdelete libc-970116
do tagdelete libc-970117
do tagdelete libc-970118
do tagdelete libc-970119
do tagdelete libc-970120
do tagdelete libc-970121
do tagdelete libc-970122
do tagdelete libc-970123
do tagdelete libc-970124
do tagdelete libc-970125
do tagdelete libc-970126
do tagdelete libc-970127
do tagdelete libc-970128
do tagdelete libc-970129
do tagdelete libc-970130
do tagdelete libc-970131
do tagdelete libc-970201
do tagdelete libc-970202
do tagdelete libc-970203
do tagdelete libc-970204
do tagdelete libc-970205
do tagdelete libc-970206
do tagdelete libc-970207
do tagdelete libc-970208
do tagdelete libc-970209
do tagdelete libc-970210
do tagdelete libc-970211
do tagdelete libc-970212
do tagdelete libc-970213
do tagdelete libc-970214
do tagdelete libc-970215
do tagdelete libc-970216
do tagdelete libc-970217
do tagdelete libc-970218
do tagdelete libc-970219
do tagdelete libc-970220
do tagdelete libc-970221
do tagdelete libc-970222
do tagdelete libc-970223
do tagdelete libc-970224
do tagdelete libc-970225
do tagdelete libc-970226
do tagdelete libc-970227
do tagdelete libc-970228
do tagdelete libc-970301
do tagdelete libc-970302
do tagdelete libc-970303
do tagdelete libc-970304
do tagdelete libc-970305
do tagdelete libc-970306
do tagdelete libc-970307
do tagdelete libc-970308
do tagdelete libc-970309
do tagdelete libc-970310
do tagdelete libc-970311
do tagdelete libc-970312
do tagdelete libc-970313
do tagdelete libc-970314
do tagdelete libc-970315
do tagdelete libc-970316
do tagdelete libc-970317
do tagdelete libc-970318
do tagdelete libc-970319
do tagdelete libc-970320
do tagdelete libc-970321
do tagdelete libc-970322
do tagdelete libc-970323
do tagdelete libc-970324
do tagdelete libc-970325
do tagdelete libc-970326
do tagdelete libc-970327
do tagdelete libc-970328
do tagdelete libc-970329
do tagdelete libc-970330
do tagdelete libc-970331
do tagdelete libc-970401
do tagdelete libc-970402
do tagdelete libc-970403
do tagdelete libc-970404
do tagdelete libc-970405
do tagdelete libc-970406
do tagdelete libc-970407
do tagdelete libc-970408
do tagdelete libc-970409
do tagdelete libc-970410
do tagdelete libc-970411
do tagdelete libc-970412
do tagdelete libc-970413
do tagdelete libc-970414
do tagdelete libc-970415
do tagdelete libc-970416
do tagdelete libc-970417
do tagdelete libc-970418
do tagdelete libc-970419
do tagdelete libc-970420
do tagdelete libc-970421
do tagdelete libc-970422
do tagdelete libc-970423
do tagdelete libc-970424
do tagdelete libc-970425
do tagdelete libc-970426
do tagdelete libc-970427
do tagdelete libc-970428
do tagdelete libc-970429
do tagdelete libc-970430
do tagdelete libc-970501
do tagdelete libc-970502
do tagdelete libc-970503
do tagdelete libc-970504
do tagdelete libc-970505
do tagdelete libc-970506
do tagdelete libc-970507
do tagdelete libc-970508
do tagdelete libc-970509
do tagdelete libc-970510
do tagdelete libc-970511
do tagdelete libc-970512
do tagdelete libc-970513
do tagdelete libc-970514
do tagdelete libc-970515
do tagdelete libc-970516
do tagdelete libc-970517
do tagdelete libc-970518
do tagdelete libc-970519
do tagdelete libc-970520
do tagdelete libc-970521
do tagdelete libc-970522
do tagdelete libc-970523
do tagdelete libc-970524
do tagdelete libc-970525
do tagdelete libc-970526
do tagdelete libc-970527
do tagdelete libc-970528
do tagdelete libc-970529
do tagdelete libc-970530
do tagdelete libc-970531
do tagdelete libc-970601
do tagdelete libc-970602
do tagdelete libc-970603
do tagdelete libc-970604
do tagdelete libc-970605
do tagdelete libc-970606
do tagdelete libc-970607
do tagdelete libc-970608
do tagdelete libc-970609
do tagdelete libc-970610
do tagdelete libc-970611
do tagdelete libc-970612
do tagdelete libc-970613
do tagdelete libc-970614
do tagdelete libc-970615
do tagdelete libc-970616
do tagdelete libc-970617
do tagdelete libc-970618
do tagdelete libc-970619
do tagdelete libc-970620
do tagdelete libc-970621
do tagdelete libc-970622
do tagdelete libc-970624
do tagdelete libc-970625
do tagdelete libc-970626
do tagdelete libc-970627
do tagdelete libc-970628
do tagdelete libc-970629
do tagdelete libc-970630
do tagdelete libc-970701
do tagdelete libc-970702
do tagdelete libc-970703
do tagdelete libc-970704
do tagdelete libc-970705
do tagdelete libc-970707
do tagdelete libc-970708
do tagdelete libc-970709
do tagdelete libc-970710
do tagdelete libc-970713
do tagdelete libc-970715
do tagdelete libc-970717
do tagdelete libc-970718
do tagdelete libc-970719
do tagdelete libc-970720
do tagdelete libc-970721
do tagdelete libc-970722
do tagdelete libc-970723
do tagdelete libc-970724
do tagdelete libc-970725
do tagdelete libc-970726
do tagdelete libc-970727
do tagdelete libc-970728
do tagdelete libc-970729
do tagdelete libc-970730
do tagdelete libc-970731
do tagdelete libc-970801
do tagdelete libc-970802
do tagdelete libc-970803
do tagdelete libc-970804
do tagdelete libc-970805
do tagdelete libc-970806
do tagdelete libc-970807
do tagdelete libc-970808
do tagdelete libc-970809
do tagdelete libc-970810
do tagdelete libc-970811
do tagdelete libc-970812
do tagdelete libc-970813
do tagdelete libc-970814
do tagdelete libc-970815
do tagdelete libc-970816
do tagdelete libc-970817
do tagdelete libc-970818
do tagdelete libc-970819
do tagdelete libc-970820
do tagdelete libc-970821
do tagdelete libc-970822
do tagdelete libc-970823
do tagdelete libc-970824
do tagdelete libc-970825
do tagdelete libc-970826
do tagdelete libc-970827
do tagdelete libc-970828
do tagdelete libc-970829
do tagdelete libc-970830
do tagdelete libc-970831
do tagdelete libc-970901
do tagdelete libc-970902
do tagdelete libc-970903
do tagdelete libc-970904
do tagdelete libc-970905
do tagdelete libc-970906
do tagdelete libc-970907
do tagdelete libc-970908
do tagdelete libc-970911
do tagdelete libc-970912
do tagdelete libc-970913
do tagdelete libc-970914
do tagdelete libc-970915
do tagdelete libc-970916
do tagdelete libc-970917
do tagdelete libc-970918
do tagdelete libc-970919
do tagdelete libc-970920
do tagdelete libc-970921
do tagdelete libc-970922
do tagdelete libc-970923
do tagdelete libc-970924
do tagdelete libc-970925
do tagdelete libc-970926
do tagdelete libc-970927
do tagdelete libc-970928
do tagdelete libc-970929
do tagdelete libc-970930
do tagdelete libc-971001
do tagdelete libc-971018
do tagdelete libc-971019
do tagdelete libc-971020
do tagdelete libc-971021
do tagdelete libc-971022
do tagdelete libc-971023
do tagdelete libc-971024
do tagdelete libc-971025
do tagdelete libc-971026
do tagdelete libc-971027
do tagdelete libc-971028
do tagdelete libc-971029
do tagdelete libc-971030
do tagdelete libc-971031
do tagdelete libc-971101
do tagdelete libc-971102
do tagdelete libc-971103
do tagdelete libc-971104
do tagdelete libc-971105
do tagdelete libc-971106
do tagdelete libc-971107
do tagdelete libc-971108
do tagdelete libc-971109
do tagdelete libc-971110
do tagdelete libc-971111
do tagdelete libc-971112
do tagdelete libc-971113
do tagdelete libc-971114
do tagdelete libc-971115
do tagdelete libc-971116
do tagdelete libc-971117
do tagdelete libc-971118
do tagdelete libc-971120
do tagdelete libc-971121
do tagdelete libc-971122
do tagdelete libc-971123
do tagdelete libc-971124
do tagdelete libc-971125
do tagdelete libc-971126
do tagdelete libc-971127
do tagdelete libc-971128
do tagdelete libc-971129
do tagdelete libc-971130
do tagdelete libc-971201
do tagdelete libc-971203
do tagdelete libc-971204
do tagdelete libc-971205
do tagdelete libc-971206
do tagdelete libc-971207
do tagdelete libc-971208
do tagdelete libc-971209
do tagdelete libc-971210
do tagdelete libc-971211
do tagdelete libc-971212
do tagdelete libc-971213
do tagdelete libc-971214
do tagdelete libc-971217
do tagdelete libc-971218
do tagdelete libc-971219
do tagdelete libc-971220
do tagdelete libc-971221
do tagdelete libc-971222
do tagdelete libc-971223
do tagdelete libc-971224
do tagdelete libc-971225
do tagdelete libc-971226
do tagdelete libc-971227
do tagdelete libc-971228
do tagdelete libc-971229
do tagdelete libc-971230
do tagdelete libc-971231
do tagdelete libc-980103
do tagdelete libc-980104
do tagdelete libc-980105
do tagdelete libc-980106
do tagdelete libc-980107
do tagdelete libc-980108
do tagdelete libc-980109
do tagdelete libc-980110
do tagdelete libc-980111
do tagdelete libc-980112
do tagdelete libc-980114
do tagdelete libc-980115
do tagdelete libc-980116
do tagdelete libc-980117
do tagdelete libc-980118
do tagdelete libc-980119
do tagdelete libc-980120
do tagdelete libc-980121
do tagdelete libc-980122
do tagdelete libc-980123
do tagdelete libc-980124
do tagdelete libc-980125
do tagdelete libc-980126
do tagdelete libc-980127
do tagdelete libc-980128
do tagdelete libc-980129
do tagdelete libc-980130
do tagdelete libc-980212
do tagdelete libc-980213
do tagdelete libc-980214
do tagdelete libc-980215
do tagdelete libc-980216
do tagdelete libc-980217
do tagdelete libc-980218
do tagdelete libc-980219
do tagdelete libc-980220
do tagdelete libc-980221
do tagdelete libc-980222
do tagdelete libc-980223
do tagdelete libc-980224
do tagdelete libc-980225
do tagdelete libc-980226
do tagdelete libc-980227
do tagdelete libc-980228
do tagdelete libc-980301
do tagdelete libc-980302
do tagdelete libc-980303
do tagdelete libc-980304
do tagdelete libc-980306
do tagdelete libc-980307
do tagdelete libc-980308
do tagdelete libc-980309
do tagdelete libc-980310
do tagdelete libc-980311
do tagdelete libc-980312
do tagdelete libc-980313
do tagdelete libc-980314
do tagdelete libc-980315
do tagdelete libc-980316
do tagdelete libc-980317
do tagdelete libc-980318
do tagdelete libc-980319
do tagdelete libc-980320
do tagdelete libc-980321
do tagdelete libc-980322
do tagdelete libc-980323
do tagdelete libc-980324
do tagdelete libc-980325
do tagdelete libc-980326
do tagdelete libc-980327
do tagdelete libc-980328
do tagdelete libc-980329
do tagdelete libc-980330
do tagdelete libc-980331
do tagdelete libc-980401
do tagdelete libc-980402
do tagdelete libc-980403
do tagdelete libc-980404
do tagdelete libc-980405
do tagdelete libc-980406
do tagdelete libc-980407
do tagdelete libc-980408
do tagdelete libc-980409
do tagdelete libc-980410
do tagdelete libc-980411
do tagdelete libc-980412
do tagdelete libc-980413
do tagdelete libc-980414
do tagdelete libc-980428
do tagdelete libc-980429
do tagdelete libc-980430
do tagdelete libc-980501
do tagdelete libc-980502
do tagdelete libc-980503
do tagdelete libc-980504
do tagdelete libc-980505
do tagdelete libc-980506
do tagdelete libc-980507
do tagdelete libc-980508
do tagdelete libc-980509
do tagdelete libc-980510
do tagdelete libc-980512
do tagdelete libc-980513
do tagdelete libc-980514
do tagdelete libc-980515
do tagdelete libc-980516
do tagdelete libc-980517
do tagdelete libc-980518
do tagdelete libc-980519
do tagdelete libc-980520
do tagdelete libc-980521
do tagdelete libc-980522
do tagdelete libc-980523
do tagdelete libc-980524
do tagdelete libc-980525
do tagdelete libc-980526
do tagdelete libc-980527
do tagdelete libc-980528
do tagdelete libc-980529
do tagdelete libc-980530
do tagdelete libc-980531
do tagdelete libc-980601
do tagdelete libc-980602
do tagdelete libc-980603
do tagdelete libc-980604
do tagdelete libc-980605
do tagdelete libc-980606
do tagdelete libc-980607
do tagdelete libc-980608
do tagdelete libc-980609
do tagdelete libc-980610
do tagdelete libc-980611
do tagdelete libc-980612
do tagdelete libc-980613
do tagdelete libc-980614
do tagdelete libc-980615
do tagdelete libc-980616
do tagdelete libc-980617
do tagdelete libc-980618
do tagdelete libc-980619
do tagdelete libc-980620
do tagdelete libc-980621
do tagdelete libc-980622
do tagdelete libc-980623
do tagdelete libc-980624
do tagdelete libc-980625
do tagdelete libc-980626
do tagdelete libc-980627
do tagdelete libc-980628
do tagdelete libc-980629
do tagdelete libc-980630
do tagdelete libc-980701
do tagdelete libc-980702
do tagdelete libc-980703
do tagdelete libc-980704
do tagdelete libc-980705
do tagdelete libc-980706
do tagdelete libc-980707
do tagdelete libc-980708
do tagdelete libc-980709
do tagdelete libc-980710
do tagdelete libc-980711
do tagdelete libc-980712
do tagdelete libc-980713
do tagdelete libc-980714
do tagdelete libc-980715
do tagdelete libc-980716
do tagdelete libc-980717
do tagdelete libc-980718
do tagdelete libc-980719
do tagdelete libc-980720
do tagdelete libc20x-970306
do tagdelete libc20x-97031
do tagdelete libc20x-970316
do tagdelete libc20x-970318
do tagdelete libc20x-970319
do tagdelete libc20x-970404
do tagdelete libc20x-970417
do tagdelete libc_1_09
do tagdelete lisp-bob
do tagdelete make-3-72-10
do tagdelete make-3-72-11
do tagdelete make-3-72-12
do tagdelete make-3-72-13
do tagdelete make-3-72-9
do tagdelete make-3-73
do tagdelete make-3-73-1
do tagdelete make-3-73-2
do tagdelete make-3-73-3
do tagdelete make-3-74
do tagdelete make-3-74-1
do tagdelete make-3-74-2
do tagdelete make-3-74-3
do tagdelete make-3-74-4
do tagdelete make-3-74-5
do tagdelete make-3-74-6
do tagdelete make-3-74-7
do tagdelete make-3-75
do tagdelete make-3-75-1
do tagdelete make-3-75-91
do tagdelete make-3-75-92
do tagdelete make-3-75-93
do tagdelete make-3-76
do tagdelete make-3-76-1
do tagdelete make-3-77
do tagdelete merge-multi-tty-to-trunk
do tagdelete merge-unicode-to-trunk
do tagdelete mh-e-7_85
do tagdelete mh-e-7_90
do tagdelete mh-e-7_91
do tagdelete mh-e-7_92
do tagdelete mh-e-7_93
do tagdelete mh-e-7_94
do tagdelete mh-e-7_95
do tagdelete mh-e-8.2.90
do tagdelete mh-e-8.2.91
do tagdelete mh-e-8.2.92
do tagdelete mh-e-8.2.93
do tagdelete mh-e-8.3
##do tagdelete mh-e-8.3.1
do tagdelete mh-e-8.4
do tagdelete mh-e-8.5
do tagdelete mh-e-8_0
do tagdelete mh-e-8_0_1
do tagdelete mh-e-8_0_2
do tagdelete mh-e-8_0_3
do tagdelete mh-e-8_1
do tagdelete mh-e-8_2
do tagdelete mh-e-doc-7_94
do tagdelete mh-e-doc-8.3
do tagdelete mh-e-doc-8.4
do tagdelete mh-e-doc-8.5
do tagdelete mh-e-doc-8_0
do tagdelete mh-e-doc-8_0_1
do tagdelete mh-e-doc-8_0_3
do tagdelete mh-e-doc-8_1
do tagdelete mh-e-doc-8_2
do tagdelete multi-tty-base
##do tagdelete patches_21_0_base
do tagdelete raeburn-tag-4-for-export
do tagdelete raeburn-tag-5-for-export
do tagdelete raeburn-tag-6-for-export
do tagdelete raeburn-tag-7-for-export
do tagdelete release-0-0
do tagdelete release-0-1
do tagdelete release-1-0
do tagdelete remove-carbon
do tagdelete remove-vms
do tagdelete root-libc-2_0_x-branch
do tagdelete small-dump-base
do tagdelete sml-mode-6.0
do tagdelete sml-mode-6.1
do tagdelete tmp_pcl_tag_131034C
# keep ttn-vms-21-2-B2
# keep ttn-vms-21-2-B3
# keep ttn-vms-21-2-B4
do tagdelete unicode-post-font-backend
do tagdelete unicode-pre-font-backend
do tagdelete unicode-xft-base
do tagdelete v0.1
do tagdelete v0.1.0
do tagdelete v0.1.1
do tagdelete v0.1.2
do tagdelete v0.1.3
do tagdelete v0.2.0
do tagdelete v0.3.0
do tagdelete v1_7i
do tagdelete v2007-Sep-10
do tagdelete xwidget-0.2
do tagdelete zsh-merge-ognus-1
do tagdelete zsh-sync-ognus-2
do tagdelete zsh-sync-ognus-3
undefine tagdelete
undefine tagrename
#
# These look like branches but are just obsolete tags
#
tag delete remotes/origin/other-branches/gerd_0001
tag delete remotes/origin/other-branches/gerd_int
tag delete remotes/origin/other-branches/miles-orphaned-changes
tag delete remotes/origin/old-branches/pending
#
# There are a number of branches that are (incorrectly) labeled
# as remotes even after having been merged, for hysterical raisins. Fix this.
#
define deremote tag remotes/origin/{0} rename {0}
do deremote emacs23
do deremote emacs24
do deremote cedet-branch
do deremote emacs-unicode
do deremote gerd-defvaralias
do deremote gnus-5_10-branch
do deremote lexbind-new
do deremote multi-tty
do deremote pending
do deremote profiler
do deremote python
do deremote rmail-mbox-branch
do deremote pending
undefine deremote
#
# Prune obsolete branches
#
branch delete origin/old-branches/elpa
#
# Fix up fossil references in ChangeLogs
# It's OK if this list isn't quite complete yet, fixing up most
# references will make the unmatched ones stick out like sore thumbs.
# 
# Some known defects and false matches: 
# 1. revisions 1.59 and 1.61 of TUTORIAL can no longer be identified
# in the RCS - likely because of a file move
# 2. "cvs-1.12.1" is not a reference to a CVS revision, rather it's
# reference to a revision of CVS.
#
# The instances of (?![0-9]) prevent false matches on prefixes of
# a Bazaar or CVS revision.
define changelog =B & [/ChangeLog/] filter --replace /{0}(?![0-9])/{1}/
define changecomment =C filter --replace /{0}(?![0-9])/{1}/
do changelog "100984" "2010-08-05T23:34:12Z!dann@ics.uci.edu"
do changelog "101422" "2010-09-13T15:17:01Z!michael.albinus@gmx.de"
do changelog "103083" "2011-02-02T17:59:44Z!sds@gnu.org"
do changelog "107149" "2012-02-06T22:08:41Z!larsi@gnus.org"
do changelog "109621" "2012-08-15T03:33:55Z!monnier@iro.umontreal.ca"
do changelog "2010-07-29 (revno 100939)" "2010-07-29T16:49:59Z!jan.h.d@swipnet.se"
do changelog "2011-04-26 change (bzr 104015)" "2011-04-26T11:26:05Z!dan.colascione@gmail.com"
do changelog "2011-08-30 (revision 105619)" "2011-08-30T17:32:44Z!eliz@gnu.org"
do changelog "2011-08-30 (revision 105619)" "2011-08-30T17:32:44Z!eliz@gnu.org"
do changelog "2013-12-11 (r115470)" "2013-12-11T19:01:44Z!tzz@lifelogs.com"
do changelog "Revision 1\.694" "2004-05-20T23:29:24Z!teirllm@auburn.edu"
do changelog "erc\.el 1\.39" "2007-12-01T03:41:01Z!rgm@gnu.org"
do changelog "of 2012-12-20 (r111276)" "2012-12-20T11:15:38Z!michael.albinus@gmx.de"
do changelog "r112148" "2013-03-26T22:08:58Z!aidalgol@no8wireless.co.nz"
do changelog "r114834" "2013-10-29T02:50:24Z!dancol@dancol.org"
do changelog "r115470" "2013-12-11T19:01:44Z!tzz@lifelogs.com"
do changelog "r99212" "2009-12-29T07:22:00Z!nickrob@snap.net.nz"
do changelog "rev 1\.82" "1994-08-03T07:39:00Z!rms@gnu.org"
do changelog "rev 100010" "2010-04-23T16:26:11Z!monnier@iro.umontreal.ca"
do changelog "rev 102609" "2010-12-08T08:09:27Z!kfogel@red-bean.com"
do changelog "rev\. 110325" "2012-10-01T18:10:29Z!cyd@gnu.org"
do changelog "rev\. 110325" "2012-10-01T18:10:29Z!cyd@gnu.org"
do changelog "revision 1\.1" "the initial version"
do changelog "revision 1\.104, made on 2000-05-21" "2000-05-21T17:04:47Z!fx@gnu.org"
do changelog "revision 1\.117" "2008-10-29T17:42:49Z!cyd@stupidchicken.com"
do changelog "revision 1\.30  of saveplace\.el" "saveplace.el at 2005-04-10T23:32:00Z!rms@gnu.org"
do changelog "revision 1\.32 of saveplace\.el" "saveplace.el at 2005-05-29T08:36:26Z!rms@gnu.org"
do changelog "revision 1\.90 (commitid mWoPbju3pgNotDps)" "2007-07-13T18:16:17Z!kfogel@red-bean.com"
do changelog "revision 104134" "2011-05-06T07:13:19Z!eggert@cs.ucla.edu"
do changelog "revision 104625" "2011-06-18T18:49:19Z!cyd@stupidchicken.com"
do changelog "revision 106664" "2011-12-11T14:49:48Z!vincentb1@users.sourceforge.net"
do changelog "revision 106831" "2012-01-10T08:27:22Z!cyd@gnu.org"
do changelog "revision 114614 (commit of 2013-10-10)" "2013-10-10T19:15:33Z!eggert@cs.ucla.edu"
do changelog "revision 84777 on 2008-02-22" "2008-02-22T17:42:09Z!monnier@iro.umontreal.ca"
do changelog "revno 100306" "2010-05-15T21:21:30Z!raeburn@raeburn.org"
do changelog "revno 100789" "2010-07-12T05:26:57Z!handa@etlken"
do changelog "revno 100928" "2010-07-29T03:25:08Z!dann@ics.uci.edu"
do changelog "revno 101459" "2010-09-17T13:30:30Z!monnier@iro.umontreal.ca"
do changelog "revno 101688" "2010-09-30T02:53:26Z!lekktu@gmail.com"
do changelog "revno 101757" "2010-10-03T13:59:56Z!dann@ics.uci.edu"
do changelog "revno 101876" "2010-10-09T18:31:12Z!rgm@gnu.org"
do changelog "revno 101897" "2010-10-10T14:43:05Z!dann@ics.uci.edu"
do changelog "revno 101949" "2010-10-13T14:50:06Z!lekktu@gmail.com"
do changelog "revno 103623" "2011-03-11T07:24:21Z!eggert@cs.ucla.edu"
do changelog "revno 108687" "2012-06-22T21:17:42Z!eggert@cs.ucla.edu"
do changelog "revno 108687" "2012-06-22T21:17:42Z!eggert@cs.ucla.edu"
do changelog "revno 108687" "2012-06-22T21:17:42Z!eggert@cs.ucla.edu"
do changelog "revno 82799 (2007-11-30)" "2007-11-30T13:57:21Z!jasonr@gnu.org"
do changelog "revno 95090 dated 2009-03-06" "2009-03-06T07:51:52Z!handa@m17n.org"
do changelog "revno 99854\.1\.6" "2010-04-17T12:33:05Z!eliz@gnu.org"
do changelog "revno 99950" "2010-04-20T13:31:28Z!eliz@gnu.org"
do changelog "revno r112320" "2013-04-18T00:12:33Z!monnier@iro.umontreal.ca"
do changelog "revno:100708" "2010-07-04T07:50:25Z!dann@ics.uci.edu"
do changelog "revno:101730 (2010-10-02)" "2010-10-02T13:21:43Z!michael.albinus@gmx.de"
do changelog "revno:101913" "2010-10-11T23:57:49Z!lekktu@gmail.com"
do changelog "revno:102982 (2011-01-26)" "2011-01-26T20:02:07Z!monnier@iro.umontreal.ca"
do changelog "revno:103013" "2011-01-28T22:12:05Z!monnier@iro.umontreal.ca"
do changelog "revno:103877 (2011-04-09)" "2011-04-09T20:28:01Z!cyd@stupidchicken.com"
do changelog "revno:104787 (2011-06-30)" "2011-06-30T01:09:13Z!larsi@gnus.org"
do changelog "revno:104988 (2011-07-06)" "2011-07-06T15:49:19Z!larsi@gnus.org"
do changelog "revno:105007" "2011-07-07T04:21:49Z!handa@m17n.org"
do changelog "revno:105285" "2011-07-19T15:01:49Z!larsi@gnus.org"
do changelog "revno:106608" "2011-12-04T17:13:01Z!lekktu@gmail.com"
do changelog "revno:108341" "2012-05-22T16:20:27Z!eggert@cs.ucla.edu"
do changelog "revno:108521" "2012-06-08T08:44:45Z!eliz@gnu.org"
do changelog "revno:108936" "2012-07-07T10:34:37Z!cyd@gnu.org"
do changelog "revno:109911" "2012-09-07T04:15:56Z!dgutov@yandex.ru"
do changelog "revno:110851" "2012-11-09T04:10:16Z!monnier@iro.umontreal.ca"
do changelog "revno:113117" "2013-06-21T12:24:37Z!lekktu@gmail.com"
do changelog "revno:113147" "2013-06-23T20:29:18Z!lekktu@gmail.com"
do changelog "revno:113431" "2013-07-16T11:41:06Z!jan.h.d@swipnet.se"
do changelog "revno:113431" "2013-07-16T11:41:06Z!jan.h.d@swipnet.se"
do changelog "revno:113793" "2013-08-11T00:07:48Z!lekktu@gmail.com"
do changelog "revno:114543" "2013-10-07T01:28:34Z!sdl.web@gmail.com"
do changelog "revno:14998 (1996-04-12)" "1996-04-12T06:01:29Z!rms@gnu.org"
do changelog "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org"
do changelog "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org"
do changelog "revno:20569 (1998-01-02)" "1998-01-02T21:29:48Z!rms@gnu.org"
do changelog "revno:20870 (1998-02-08)" "1998-02-08T21:33:56Z!rms@gnu.org"
do changelog "revno:25013 (1999-07-21)" "1999-07-21T21:43:52Z!gerd@gnu.org"
do changelog "revno:25013 (1999-07-21)" "1999-07-21T21:43:52Z!gerd@gnu.org"
do changelog "revno:25356 (1999-08-21)" "1999-08-21T19:30:21Z!gerd@gnu.org"
do changelog "revno:32591 (2000-10-17)" "2000-10-17T16:08:18Z!gerd@gnu.org"
do changelog "revno:34925 (2000-12-29)" "2000-12-29T14:24:09Z!gerd@gnu.org"
do changelog "revno:36704 (2001-03-09)" "2001-03-09T18:41:50Z!gerd@gnu.org"
do changelog "revno:43563\.1\.17 (2002-03-01)" "2002-03-01T01:17:24Z!handa@m17n.org"
do changelog "revno:43563\.1\.32 (2002-03-01)" "2002-03-01T01:17:24Z!handa@m17n.org"
do changelog "revno:50135 (2003-03-16)" "2003-03-16T20:45:46Z!storm@cua.dk"
do changelog "revno:84043 (2008-02-1)" "2008-02-01T16:01:31Z!miles@gnu.org"
do changelog "revno:86854 (2008-04-19)" "2008-04-19T19:30:53Z!monnier@iro.umontreal.ca"
do changelog "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org"
do changelog "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org"
do changelog "revno:88805" "2008-06-21T01:38:39Z!monnier@iro.umontreal.ca"
do changelog "revno:88864" "2008-06-22T13:57:28Z!monnier@iro.umontreal.ca"
do changelog "revno:89810" "2008-07-31T05:33:56Z!dann@ics.uci.edu"
do changelog "revno:99634\.2\.463 (2010-10-09)" "2010-10-09T04:09:19Z!cyd@stupidchicken.com"
do changelog "revno\n103471" "\n2011-03-02T03:48:01Z!cyd@stupidchicken.com"
do changelog "revnos 100982" "2010-08-05T23:15:24Z!dann@ics.uci.edu"
do changelog "revnos 101381" "2010-09-08T14:42:54Z!michael.albinus@gmx.de"
do changelog "the 2011-04-14 change (bzr 103913)" "2011-04-14T23:19:38Z!eggert@cs.ucla.edu"
do changelog "version 1\.100" "2007-12-06T19:56:41Z!deego@gnufans.org"
do changelog "revision 1\.59" "CVS revision 1.59"
do changecomment "1\.39" "2007-12-01T03:41:01Z!rgm@gnu.org"
do changecomment "103071" "2011-02-01T18:15:18Z!sds@gnu.org"
do changecomment "103199" "2011-02-09T17:04:43Z!schwab@linux-m68k.org"
do changecomment "106124" "2011-10-18T16:56:09Z!eliz@gnu.org"
do changecomment "108099" "2012-05-02T11:38:01Z!lekktu@gmail.com"
do changecomment "109252" "2012-07-28T23:05:32Z!eggert@cs.ucla.edu"
do changecomment "109542" "2012-08-10T06:54:37Z!eliz@gnu.org"
do changecomment "109766" "2012-08-25T04:27:32Z!eggert@cs.ucla.edu"
do changecomment "111840" "2013-02-21T02:42:30Z!eggert@cs.ucla.edu"
do changecomment "114527" "2013-10-05T02:26:39Z!dgutov@yandex.ru"
do changecomment "2005-02-15 (revno 60055)" "2005-02-15T23:19:26Z!jasonr@gnu.org"
do changecomment "2011-04-26 change (bzr 104015)" "2011-04-26T11:26:05Z!dan.colascione@gmail.com"
do changecomment "2011-08-30 (revision 105619)" "2011-08-30T17:32:44Z!eliz@gnu.org"
do changecomment "bzrs 111300" "2012-12-22T19:57:35Z!rgm@gnu.org"
do changecomment "change 103083" "2011-02-02T17:59:44Z!sds@gnu.org"
do changecomment "commit 115961" "2014-01-10T12:41:19Z!ruediger@c-plusplus.de"
do changecomment "patch 99592" "2010-03-01T11:31:42Z!acm@muc.de"
do changecomment "r1\.135" "2009-10-10T21:48:22Z!kfogel@red-bean.com"
do changecomment "r100577" "2010-06-10T12:56:11Z!michael.albinus@gmx.de"
do changecomment "r111320" "2012-12-24T15:56:17Z!eliz@gnu.org"
do changecomment "rev 1\.82" "1994-08-03T07:39:00Z!rms@gnu.org"
do changecomment "rev 100010" "2010-04-23T16:26:11Z!monnier@iro.umontreal.ca"
do changecomment "rev 102609" "2010-12-08T08:09:27Z!kfogel@red-bean.com"
do changecomment "rev 109972" "2012-09-10T21:01:45Z!jan.h.d@swipnet.se"
do changecomment "rev 110325" "2012-10-01T18:10:29Z!cyd@gnu.org"
do changecomment "rev 99553" "2010-02-24T22:07:26Z!bob@gnu.org"
do changecomment "rev 99649" "2010-03-12T16:34:27Z!eliz@gnu.org"
do changecomment "revision 1\.1" "initial revision"
do changecomment "revision 1\.117" "2008-10-29T17:42:49Z!cyd@stupidchicken.com"
do changecomment "revision 1\.30" "2005-04-10T23:32:00Z!rms@gnu.org"
do changecomment "revision 1\.32" "2005-05-29T08:36:26Z!rms@gnu.org"
do changecomment "revision 1\.90 (commitid mWoPbju3pgNotDps)" "2007-07-13T18:16:17Z!kfogel@red-bean.com"
do changecomment "revision 102407" "2010-11-16T19:59:24Z!cyd@stupidchicken.com"
do changecomment "revision 102572" "2010-12-03T11:52:43Z!yamaoka@jpl.org"
do changecomment "revision 103104" "2011-02-03T19:30:24Z!eggert@cs.ucla.edu"
do changecomment "revision 103365" "2011-02-20T18:50:26Z!eliz@gnu.org"
do changecomment "revision 103378" "2011-02-22T00:15:53Z!eggert@cs.ucla.edu"
do changecomment "revision 103558" "2011-03-06T08:31:32Z!eggert@cs.ucla.edu"
do changecomment "revision 103643" "2011-03-13T06:43:00Z!eggert@cs.ucla.edu"
do changecomment "revision 103792" "2011-03-31T19:12:30Z!eliz@gnu.org"
do changecomment "revision 103798" "2011-04-01T17:19:52Z!monnier@iro.umontreal.ca"
do changecomment "revision 103841" "2011-04-06T05:19:39Z!eggert@cs.ucla.edu"
do changecomment "revision 104264" "2011-05-18T00:35:01Z!eggert@cs.ucla.edu"
do changecomment "revision 104265" "2011-05-18T00:52:24Z!eggert@cs.ucla.edu"
do changecomment "revision 104320" "2011-05-22T19:46:47Z!cyd@stupidchicken.com"
do changecomment "revision 104551" "2011-06-10T06:55:18Z!rudalics@gmx.at"
do changecomment "revision 106131" "2011-10-19T09:48:35Z!eliz@gnu.org"
do changecomment "revision 106293" "2011-11-05T12:04:34Z!jan.h.d@swipnet.se"
do changecomment "revision 106664" "2011-12-11T14:49:48Z!vincentb1@users.sourceforge.net"
do changecomment "revision 106726" "2011-12-23T14:51:51Z!eliz@gnu.org"
do changecomment "revision 106726" "2011-12-23T14:51:51Z!eliz@gnu.org"
do changecomment "revision 106798" "2012-01-06T08:10:22Z!rgm@gnu.org"
do changecomment "revision 106831" "2012-01-10T08:27:22Z!cyd@gnu.org"
do changecomment "revision 108149" "2012-05-07T20:48:41Z!monnier@iro.umontreal.ca"
do changecomment "revision 10835" "1995-02-25T20:57:45Z!rms@gnu.org"
do changecomment "revision 108801" "2012-06-29T11:48:08Z!dmantipov@yandex.ru"
do changecomment "revision 109685" "2012-08-19T21:00:09Z!eggert@cs.ucla.edu"
do changecomment "revision 109836" "2012-09-01T08:01:36Z!dancol@dancol.org"
do changecomment "revision 109909" "2012-09-07T01:27:44Z!eggert@cs.ucla.edu"
do changecomment "revision 110152" "2012-09-23T08:44:20Z!eggert@cs.ucla.edu"
do changecomment "revision 110608" "2012-10-21T01:19:46Z!rgm@gnu.org"
do changecomment "revision 110889" "2012-11-14T04:55:41Z!eggert@cs.ucla.edu"
do changecomment "revision 111151" "2012-12-08T02:30:51Z!eggert@cs.ucla.edu"
do changecomment "revision 111602" "2013-01-25T10:27:16Z!eliz@gnu.org"
do changecomment "revision 111647" "2013-02-01T07:23:18Z!dmantipov@yandex.ru"
do changecomment "revision 112072" "2013-03-18T04:30:20Z!eggert@cs.ucla.edu"
do changecomment "revision 113315" "2013-07-07T18:00:14Z!eggert@cs.ucla.edu"
do changecomment "revision 115838" "2014-01-02T21:05:34Z!vincentb1@users.sourceforge.net"
do changecomment "revision 115841" "2014-01-02T22:54:37Z!vincentb1@users.sourceforge.net"
do changecomment "revision 84777 on 2008-02-22" "2008-02-22T17:42:09Z!monnier@iro.umontreal.ca"
do changecomment "revision 87208" "2008-05-02T07:12:59Z!esr@snark.thyrsus.com"
do changecomment "revision 94343" "2009-01-30T13:06:07Z!lekktu@gmail.com"
do changecomment "revision 99649" "2010-03-12T16:34:27Z!eliz@gnu.org"
do changecomment "revisions 103189" "2011-02-08T21:42:56Z!tromey@redhat.com"
do changecomment "revisions 109765" "2012-08-25T04:04:08Z!eggert@cs.ucla.edu"
do changecomment "revno 95090 dated 2009-03-06" "2009-03-06T07:51:52Z!handa@m17n.org"
do changecomment "revno 99212" "2009-12-29T07:22:00Z!nickrob@snap.net.nz"
do changecomment "revno 99854\.1\.6" "2010-04-17T12:33:05Z!eliz@gnu.org"
do changecomment "revno 99950" "2010-04-20T13:31:28Z!eliz@gnu.org"
do changecomment "revno:101913 (2010-10-12)\." "2010-10-11T23:57:49Z!lekktu@gmail.com"
do changecomment "revno:11026" "1995-03-15T21:55:37Z!kwzh@gnu.org"
do changecomment "revno:14998 (1996-04-12)" "1996-04-12T06:01:29Z!rms@gnu.org"
do changecomment "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org"
do changecomment "revno:20537 (1998-01-01)" "1998-01-01T02:27:27Z!rms@gnu.org"
do changecomment "revno:20569 (1998-01-02)" "1998-01-02T21:29:48Z!rms@gnu.org"
do changecomment "revno:20870 (1998-02-08)" "1998-02-08T21:33:56Z!rms@gnu.org"
do changecomment "revno:25013 (1999-07-21)" "1999-07-21T21:43:52Z!gerd@gnu.org"
do changecomment "revno:25356 (1999-08-21)" "1999-08-21T19:30:21Z!gerd@gnu.org"
do changecomment "revno:32591 (2000-10-17)" "2000-10-17T16:08:18Z!gerd@gnu.org"
do changecomment "revno:34925 (2000-12-29)" "2000-12-29T14:24:09Z!gerd@gnu.org"
do changecomment "revno:36704 (2001-03-09)" "2001-03-09T18:41:50Z!gerd@gnu.org"
do changecomment "revno:43563\.1\.16 (2002-03-01)" "2002-03-01T01:16:34Z!handa@m17n.org"
do changecomment "revno:84043 (2008-02-1)" "2008-02-01T16:01:31Z!miles@gnu.org"
do changecomment "revno:86854 (2008-04-19)" "2008-04-19T19:30:53Z!monnier@iro.umontreal.ca"
do changecomment "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org"
do changecomment "revno:87605 (2008-05-14)" "2008-05-14T01:40:23Z!handa@m17n.org"
do changecomment "revno:88805" "2008-06-21T01:38:39Z!monnier@iro.umontreal.ca"
do changecomment "revno:88864" "2008-06-22T13:57:28Z!monnier@iro.umontreal.ca"
do changecomment "revno:89810" "2008-07-31T05:33:56Z!dann@ics.uci.edu"
do changecomment "revno:99634\.2\.463 (2010-10-09)" "2010-10-09T04:09:19Z!cyd@stupidchicken.com"
do changecomment "the 2011-04-14 change (bzr 103913)" "2011-04-14T23:19:38Z!eggert@cs.ucla.edu"
do changecomment "version 1\.100" "2007-12-06T19:56:41Z!deego@gnufans.org"
undefine changelog 
undefine changecomment
#
# Fix up ignore files
#
# Remove every .cvsignore not older than when .gitignores were
# first added.  Then rename all remaining (older) .cvsignores to
# corresponding .gitignore paths; the syntax is upward-compatible.
# The date marks the introduction of .gitignore files.
#
<2009-02-03T23:32:38Z>..$ & [/.cvsignore/] expunge
path (.*)/.cvsignore rename \1/.gitignore
#
# Then treat .bzrignore files as authoritative, after changing leading
# "./" to "/".  (The only other syntax incompatibility is "RE:", which
# the Emacs repository never uses.) The date marks the introduction of
# .bzrignore files.
#
<2009-12-27T21:38:14Z>..$ & [/.gitignore/] expunge
filter [\.bzrignore] filter --regex :^./:/:
path (.*)/.bzrignore rename \1/.gitignore


-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Andreas Schwab]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> tag delete remotes/origin/other-branches/gerd_0001

I think you should be operating on a mirror where there is no
refs/remotes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Repo cpnversion progress report

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > tag delete remotes/origin/other-branches/gerd_0001
> 
> I think you should be operating on a mirror where there is no
> refs/remotes.

I'm operating on a pull of the git mirror.  Can you be more
explicit about what you think I should be doing instead?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Eli Zaretskii]

> Date: Thu, 30 Jan 2014 14:55:57 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> 
> The current version of the reposurgeon conversion script follows.  The
> header comment explains the major steps.  Most can be sanity-checked 
> by eyeball and a little investigation with git log or gitk; interested
> parties are invited to do so. 

The list of bzr revisions in changecomment lines is still too short,
about one third of the real list.

Also, it looks like you are going to _replace_ the revision numbers
with the time stamp, not just _add_ the time stamp?  If so, I strongly
suggest to leave the revision numbers intact, so that we don't lose
information.

> # Fix up ignore files
> #
> # Remove every .cvsignore not older than when .gitignores were
> # first added.  Then rename all remaining (older) .cvsignores to
> # corresponding .gitignore paths; the syntax is upward-compatible.
> # The date marks the introduction of .gitignore files.

This looks gratuitous and loses information.  I think you shouldn't be
doing that.

Re: Repo cpnversion progress report

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> The list of bzr revisions in changecomment lines is still too short,
> about one third of the real list.

I went through the putput of bzr log --levels 0 with grep and eyeball
last night; those are what I found.

It would be helpful if you were to supply what you think of as the
real list.

> Also, it looks like you are going to _replace_ the revision numbers
> with the time stamp, not just _add_ the time stamp?  If so, I strongly
> suggest to leave the revision numbers intact, so that we don't lose
> information.

After we change over, the Bazaar revision numbers will be meaningless
except as keys to a map file which is just going to associate them
with the action stamps I'm replacing them with.

Please explain what information you think is being lost here, because
I don't get it. 

> > # Remove every .cvsignore not older than when .gitignores were
> > # first added.  Then rename all remaining (older) .cvsignores to
> > # corresponding .gitignore paths; the syntax is upward-compatible.
> > # The date marks the introduction of .gitignore files.
> 
> This looks gratuitous and loses information.  I think you shouldn't be
> doing that.

What would you do instead?  What information do you believe the newer
.cvsignores carry that the .bzrignores and .gitignores do not?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Andreas Schwab]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> I'm operating on a pull of the git mirror.  Can you be more
> explicit about what you think I should be doing instead?

git clone --mirror

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Repo cpnversion progress report

[Eli Zaretskii]

> Date: Thu, 30 Jan 2014 16:42:01 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > The list of bzr revisions in changecomment lines is still too short,
> > about one third of the real list.
> 
> I went through the putput of bzr log --levels 0 with grep and eyeball
> last night; those are what I found.

What grep command did you use?  The regexp(s) you gave to grep are the
key.

I use "bzr log" with multiple --match-message options (they accept
Python regexps), which is similar.  So the difference must come from
the regular expressions used.

> It would be helpful if you were to supply what you think of as the
> real list.

I'm sorry, but my motivation to help you at this point is nil, I'm
sure you understand why.  I even needed to debate whether to point out
that you had a very incomplete list of references.

> > Also, it looks like you are going to _replace_ the revision numbers
> > with the time stamp, not just _add_ the time stamp?  If so, I strongly
> > suggest to leave the revision numbers intact, so that we don't lose
> > information.
> 
> After we change over, the Bazaar revision numbers will be meaningless
> except as keys to a map file which is just going to associate them
> with the action stamps I'm replacing them with.

They are not meaningless, since, as you correctly recommend, the bzr
repo should be kept frozen at the point of the switch, rather than
deleted.  If something goes wrong during the conversion, and someone
needs to do some archeology later, these numbers might help.

So I suggest to make the replacements like this:

 "rev 102609" => "2010-12-08T08:09:27Z!kfogel@red-bean.com (bzr r102609)"
                                                           ^^^^^^^^^^^^^
> > > # Remove every .cvsignore not older than when .gitignores were
> > > # first added.  Then rename all remaining (older) .cvsignores to
> > > # corresponding .gitignore paths; the syntax is upward-compatible.
> > > # The date marks the introduction of .gitignore files.
> > 
> > This looks gratuitous and loses information.  I think you shouldn't be
> > doing that.
> 
> What would you do instead?  What information do you believe the newer
> .cvsignores carry that the .bzrignores and .gitignores do not?

I see no need to remove files that existed at a certain date, as that
changes history for no good reason.  We have no idea whether
.gitignores and .bzrignores were indeed 100% equivalent to .cvsignores
(it's humans who did that job, and they are prone to errors).

I certainly see no reason for this part:

  Then rename all remaining (older) .cvsignores to corresponding
  .gitignore paths; the syntax is upward-compatible.

This doesn't make sense at all to me: would you also rename a .c file
to a .el file if it was at some later point rewritten in Lisp?  If I
checkout a revision from 1990, I don't want to see a .gitignore file
that didn't exist, and I certainly _do_ want to see a .cvsignore that
did.

The .*ignore files are here to make the display of status command
cleaner, that's all.  When I checkout an old revision, I don't need
that feature, because I'm not going to commit from that point.

So I don't see what is the motivation for this history rewrite in the
first place.  What do we gain from that?

Re: Repo cpnversion progress report

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> I'm sorry, but my motivation to help you at this point is nil, I'm
> sure you understand why.

I'm sorry, but if you're not going to be helpful, then expect to be
ignored. The cost of withdrawing any cooperation is that you lose
influence over the result.  You get to take what comes out the other
end and like it.

I'm not saying this out of personal rancor. This conversion job is so
messy and labor-intensive that I simply cannot spare the energy to
listen to people I think are just going to carp about it.

Because I at least like to think I'm a reasonable person, you can
rescue this situation at any time by displaying behavioral evidence of
helpfulness.  That means doing something concrete that helps the work
along.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Eli Zaretskii <eliz@gnu.org>:
>> I'm sorry, but my motivation to help you at this point is nil, I'm
>> sure you understand why.
>
> I'm sorry, but if you're not going to be helpful, then expect to be
> ignored. The cost of withdrawing any cooperation is that you lose
> influence over the result.  You get to take what comes out the other
> end and like it.

I don't see any justification for the "and like it" angle.  I also don't
see any justification for the "you lose any influence" angle since that
implies that voting for keeping the status quo is not an option.

> I'm not saying this out of personal rancor. This conversion job is so
> messy and labor-intensive that I simply cannot spare the energy to
> listen to people I think are just going to carp about it.
>
> Because I at least like to think I'm a reasonable person, you can
> rescue this situation at any time by displaying behavioral evidence of
> helpfulness.  That means doing something concrete that helps the work
> along.

There are certainly valid opinions about the cost/benefit of throwing
the existing repository and all its references away that do not qualify
as "doing something concrete that helps the work along".

Putting a lot of work into a change does not automatically imply it has
to be accepted.

If you say that you are going to ignore any feedback that will distract
you from finishing your work properly, that's a perfectly reasonable
strategic decision.  But the cost of that wager does not lie with Eli.

A perfect pitch does not buy you a homerun (well, obviously).

-- 
David Kastrup

Re: Repo cpnversion progress report

[Eli Zaretskii]

> Date: Fri, 31 Jan 2014 10:25:18 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > I'm sorry, but my motivation to help you at this point is nil, I'm
> > sure you understand why.
> 
> I'm sorry, but if you're not going to be helpful, then expect to be
> ignored.

I'm ignored already.  You never accepted any argument of mine through
that long and tiresome "discussion".  You are always right and all
those who disagree with you are always wrong.

> The cost of withdrawing any cooperation is that you lose influence
> over the result.

I never had any influence over that, because you refuse to listen
to any dissenting arguments, and prefer to stubbornly do what you
decided was right ahead of any discussion.

> You get to take what comes out the other end and like it.

Emacs is not my project, and this conversion is not my funeral.  You
may wish to stop being obsessed by my sorry self, and start seriously
thinking of the greater good -- the good of the project with which you
are messing.  Because it's the project that will "take what comes out
the other end", not me.

> I'm not saying this out of personal rancor. This conversion job is so
> messy and labor-intensive that I simply cannot spare the energy to
> listen to people I think are just going to carp about it.

You didn't listen to begin with.

Look, you asked for comments on your progress report, and I gave them
to you.  It's up to you to act on those comments or ignore them.  The
results will speak for themselves.

> Because I at least like to think I'm a reasonable person, you can
> rescue this situation at any time by displaying behavioral evidence of
> helpfulness.

Thank you for this arrogant lecture, but I won't hold my breath if I
were you, as I don't hold mine regarding a similar change in your
behavior.

> That means doing something concrete that helps the work along.

I have no intention to help where my help is not welcome.  If you want
my help, you will need to accept and respect my judgments on what and
how should or shouldn't be done, and at least sometimes agree or
compromise.  If instead you want to use me as a workhorse that just
does as he is told and shuts up, you will have to look elsewhere.

And I suggest all the others in this project to seriously consider
whether we want to trust this job (or any job) to a man who thinks,
speaks, and acts like you do.

Re: Repo cpnversion progress report

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>They are not meaningless, since, as you correctly recommend, the bzr
>repo should be kept frozen at the point of the switch, rather than
>deleted.  If something goes wrong during the conversion, and someone
>needs to do some archeology later, these numbers might help.
>
>So I suggest to make the replacements like this:
>
> "rev 102609" => "2010-12-08T08:09:27Z!kfogel@red-bean.com (bzr r102609)"
>                                                           ^^^^^^^^^^^^^

I agree with Eli's point above, FWIW (and not just because he happened
to use one of my (sadly rarer than I would like) commits as an example).

Preserving the bzr revision number isn't very distracting -- anyone
spelunking through this stuff already has good vgrep goggles on -- and
provides a valuable trail in the event of an urgent forensic expedition.
As we all know, such expeditions occur more often than we expect, even
after we adjust our expectations accordingly :-).

I don't agree with Eli's comments in a later mail about how he wasn't
sure we should entrust this job to ESR.  It's a complex, time-consuming,
and apparently thankless task; IMHO ESR is doing a good job considering
all the inputs involved (both human and machine).

-K

Re: Repo cpnversion progress report

[Juanma Barranquero]

On Fri, Jan 31, 2014 at 6:31 PM, Karl Fogel <kfogel@red-bean.com> wrote:

> I don't agree with Eli's comments in a later mail about how he wasn't
> sure we should entrust this job to ESR.  It's a complex, time-consuming,
> and apparently thankless task; IMHO ESR is doing a good job considering
> all the inputs involved (both human and machine).

Well, do you at least agree with him when he says

> I'm ignored already.  You never accepted any argument of mine through
> that long and tiresome "discussion".  You are always right and all
> those who disagree with you are always wrong.

and

> I never had any influence over that, because you refuse to listen
> to any dissenting arguments, and prefer to stubbornly do what you
> decided was right ahead of any discussion.

?

Because that's also my feeling about every single switching-to-git
discussion we've had so far. The only thing Eric has backtracked about
is the imminence of switching, and that because Stefan specifically
said that it wouldn't happen during the freeze.

    J

Re: Repo cpnversion progress report

[Eric S. Raymond]

Karl Fogel <kfogel@red-bean.com>:
> I agree with Eli's point above, FWIW (and not just because he happened
> to use one of my (sadly rarer than I would like) commits as an example).

This could be done with a relatively simple series of changes to the lift file.

(Everybody should be paying attention to the lift script drafts!  This is
my way of exposing the conversion process to review, as well as making
it repeatable so that the cost of correcting errors is low.)

There's a practical problem with it, however. Where a Bazaar revision
number is typically 5 or 6 characters an action stamp is a minimum of
28 and typically about 40.  Fortunately we can often get some of that
back by removing an unneeded "revision" or "revno:" prefix.

Still, replacing with the action stamp already makes the patched
references unpleasantly long in some cases.  Adding the action stamp
*and* leaving the Bazaar revision in place would produce results that
in many cases are significantly harder to read.  This is the main
reason I don't want to do it.  The whole point of what I'm doing
is to *lower* the friction costs of browsing the history, not raise them.

I hear the argument about forensics, but the Bazaar revision numbers
are no more helpful for that than the action stamps. If anything,
spelunking is an argument for appending those numbers to the change
comment of each revision - leaving them in as references would a 
bass-ackwards approach to the problem.

But there's a better way.  We're going to have a complete
revision-to-action-stamp map as part of the record.  It would be
pretty easy to write Emacs code that uses that map to find revisions
by Bazaar reference number.  That's the right solution, IMO.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Eric S. Raymond]

Juanma Barranquero <lekktu@gmail.com>:
> Well, do you at least agree with him when he says
> 
> > I'm ignored already.  You never accepted any argument of mine through
> > that long and tiresome "discussion".  You are always right and all
> > those who disagree with you are always wrong.
> 
> and
> 
> > I never had any influence over that, because you refuse to listen
> > to any dissenting arguments, and prefer to stubbornly do what you
> > decided was right ahead of any discussion.

Sigh.  I wasn't going to go there, but....in fact I have already done
several work items raised specifically by Eli.  And have several more
remaining on the transition list.  A notable one is ensuring that Bazaar 
"fixes bug" metadata is preserved, something not true of the mirror now.

I'm a very reasonable person about meeting requirements like that
which are raised in a genuine attempt to improve the quality of the
result. It's for sure no one else is going to do them for you.

Being reasonable does not, however, mean I will put up with
obstreperous bullshit.  What I just quoted, from Juanma and Eli both,
was obstreperous bullshit.  That, I respond to by decreasing my
willingness to pay attention to the bullshitter.

So let me spell it out: Juanma, if you think you are not being
listened to, you have only your own bad attitude to blame for that.
Same goes for you, Eli. After enough pissy, semi-autistic territorial
grunting I just start tuning all of it out.

Conversely, you can earn my attention and increased willingness to do
what you want by putting effort into helping with the work. You can
begin an attempt to be helpful at any time you like. 

Here are some things you could do to help:

1. Identify the actual merge points of as many of the =-prefixed attic
files as possible, so I can do the cleanup Andreas wants.

2. Spot CVS cliques consisting of uncoalesced single-file changes and their
ChangeLog entry commits so I can squash them into proper changesets.

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

4. Report Bazaar and CVS references that aren't already in the
emacs.lift file.

Or, you can leave me to do all the work alone while flaming from the
sidelines. If you choose that, don't blame anyone but yourselves
if you think (wrongly) that you've had no influence on the result.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Karl Fogel]

Juanma Barranquero <lekktu@gmail.com> writes:
>On Fri, Jan 31, 2014 at 6:31 PM, Karl Fogel <kfogel@red-bean.com> wrote:
>
>> I don't agree with Eli's comments in a later mail about how he wasn't
>> sure we should entrust this job to ESR.  It's a complex, time-consuming,
>> and apparently thankless task; IMHO ESR is doing a good job considering
>> all the inputs involved (both human and machine).
>
>Well, do you at least agree with him when he says
>
>> I'm ignored already.  You never accepted any argument of mine through
>> that long and tiresome "discussion".  You are always right and all
>> those who disagree with you are always wrong.
>
>and
>
>> I never had any influence over that, because you refuse to listen
>> to any dissenting arguments, and prefer to stubbornly do what you
>> decided was right ahead of any discussion.
>
>?

My impression -- I've followed the discussions, but have not read every
single message or subthread -- is that the above is an exaggeration.

>Because that's also my feeling about every single switching-to-git
>discussion we've had so far. The only thing Eric has backtracked about
>is the imminence of switching, and that because Stefan specifically
>said that it wouldn't happen during the freeze.

The most important fact about all our prior switching-to-git discussions
was that always RMS vetoed the idea, explicitly saying that the number
of developers who wanted to switch was not relevant to the decision.  He
even continued saying this after it was obvious that Bazaar was not in
any meaningful sense a GNU project.

Given that history, I find it ironic that ESR is now being accused of
not listening enough :-).

In another followup, ESR wrote:
>I hear the argument about forensics, but the Bazaar revision numbers
>are no more helpful for that than the action stamps. If anything,
>spelunking is an argument for appending those numbers to the change
>comment of each revision - leaving them in as references would a 
>bass-ackwards approach to the problem.
>
>But there's a better way.  We're going to have a complete
>revision-to-action-stamp map as part of the record.  It would be
>pretty easy to write Emacs code that uses that map to find revisions
>by Bazaar reference number.  That's the right solution, IMO.

Okay.  I'm not able to pay as close attention to the problem as others
here are, but if you feel you've got a plan that handles the forensic
case well enough, that's fine by me.

There are a million ways to convert a bzr history to git.  We just need
to pick one of those ways that will work for Emacs development.  (insert
the usual comment about diminishing returns, lather, rinse, repeat?)

Best,
-Karl

Re: Repo cpnversion progress report

[Paul Eggert]

Eric S. Raymond wrote:
> I hear the argument about forensics, but the Bazaar revision numbers
> are no more helpful for that than the action stamps.

As someone who regularly spelunks back decades, I'd prefer keeping these 
stamps as small as possible.  Even 
"2003-07-05T12:41:24!Roland.Winkler@physik.uni-erlangen.de" will cause 
hassles, and I especially wouldn't want to read and digest monsters 
along the lines of what someone else proposed, e.g., 
"1985-04-18T00:49:29!jimb@redhat.com (bzr 1) (CVS 4.35.2.1) (RCS 1.71) 
(emacs-backup ~107~)".  It doesn't scale for a revision string to 
contain all the names that the revision has ever had, for all the 
version-control systems we've ever used.

It may be that leaving commentary alone is the simplest and best way to 
keep it short and readable, with a map elsewhere that converts old 
notation.  That being said, I'm willing to give your approach a try.  As 
long as the complete history is available somewhere and is documented, 
and it's not too much work to use it, it should be OK.

PS.  In that 1985 example, the email address jimb@redhat.com is 
ahistorical, as Red Hat didn't exist in 1985.  That info is taken 
straight from the current bzr repository.  Most likely the repository 
was made ahistorical during an earlier conversion, unfortunately.

Re: Repo cpnversion progress report

[Juanma Barranquero]

On Fri, Jan 31, 2014 at 8:23 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> What I just quoted, from Juanma and Eli both,
> was obstreperous bullshit.

Why settle for low-quality bullshit when we can do our best?

> So let me spell it out: Juanma, if you think you are not being
> listened to, you have only your own bad attitude to blame for that.

I don't worry about being listened to by you, because the only
discussion we've had, about your incompatible and ill-timed change to
the bzr-version stuff, you already made perfectly clear that, as Eli
has said, the only acceptable outcome was to acknowledge that you were
right and I was wrong. After that I'm no longer interested in the git
conversion. I don't help, and I don't interfere. Whatever will be,
will be.

But the rejection of your ways is not limited to Eli and me, not by a
long shot. Just reread your interventions and the kind of answers it
has triggered. Bad attitude indeed.

   J

Re: Repo cpnversion progress report

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Eric Raymond <esr@thyrsus.com>,  Emacs developers <emacs-devel@gnu.org>
> Date: Fri, 31 Jan 2014 13:31:37 -0600
> 
> The most important fact about all our prior switching-to-git discussions
> was that always RMS vetoed the idea, explicitly saying that the number
> of developers who wanted to switch was not relevant to the decision.  He
> even continued saying this after it was obvious that Bazaar was not in
> any meaningful sense a GNU project.
> 
> Given that history, I find it ironic that ESR is now being accused of
> not listening enough :-).

So you are saying that no one can ever be accused of not listening
enough, unless we also accuse RMS?  Is that what you are saying?

Re: Repo cpnversion progress report

[Eli Zaretskii]

> Date: Fri, 31 Jan 2014 14:23:22 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, Eli Zaretskii <eliz@gnu.org>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> I'm a very reasonable person about meeting requirements like that
> which are raised in a genuine attempt to improve the quality of the
> result.

Yeah, right.  Of course, anything that you don't agree with is not a
"genuine attempt to improve the quality", right?

> Being reasonable does not, however, mean I will put up with
> obstreperous bullshit.  What I just quoted, from Juanma and Eli both,
> was obstreperous bullshit.  That, I respond to by decreasing my
> willingness to pay attention to the bullshitter.

I guess profanities is the only defense you have left.  That's just
pathetic.

> Conversely, you can earn my attention and increased willingness to do
> what you want by putting effort into helping with the work. You can
> begin an attempt to be helpful at any time you like. 

What you are missing is that I already tried, and in response you
publicly and viciously drew me away, just a couple of hours ago.

> Or, you can leave me to do all the work alone while flaming from the
> sidelines. If you choose that, don't blame anyone but yourselves
> if you think (wrongly) that you've had no influence on the result.

No one is flaming you.  You are being pointed to the quality of your
work, which so far is inadequate.  You are also requested to do this
job as this project's members feel you should.  If you really want to
help this project, you should listen.  Instead, _you_ are flaming
_us_, something that is entirely incompatible with a wish to help.

Re: Repo cpnversion progress report

[Stefan Monnier]

> I hear the argument about forensics, but the Bazaar revision numbers
> are no more helpful for that than the action stamps. If anything,
> spelunking is an argument for appending those numbers to the change
> comment of each revision - leaving them in as references would a
> bass-ackwards approach to the problem.

Moving the "equiv to bzr r123456" to the commit message of that
corresponding Git commit sounds like an good compromise.  Of course, we
don't need it for every commit, but for all those commits that have
a corresponding "action stamp".

> But there's a better way.  We're going to have a complete
> revision-to-action-stamp map as part of the record.  It would be
> pretty easy to write Emacs code that uses that map to find revisions
> by Bazaar reference number.  That's the right solution, IMO.

But where would this map be stored?
Keeping it directly in the commit log sounds like a better approach.


        Stefan

Re: Repo cpnversion progress report

[Eric S. Raymond]

Paul Eggert <eggert@cs.ucla.edu>:
> Eric S. Raymond wrote:
> >I hear the argument about forensics, but the Bazaar revision numbers
> >are no more helpful for that than the action stamps.
> 
> As someone who regularly spelunks back decades, I'd prefer keeping
> these stamps as small as possible.  Even
> "2003-07-05T12:41:24!Roland.Winkler@physik.uni-erlangen.de" will
> cause hassles, and I especially wouldn't want to read and digest
> monsters along the lines of what someone else proposed, e.g.,
> "1985-04-18T00:49:29!jimb@redhat.com (bzr 1) (CVS 4.35.2.1) (RCS
> 1.71) (emacs-backup ~107~)".  It doesn't scale for a revision string
> to contain all the names that the revision has ever had, for all the
> version-control systems we've ever used.

Yeah, exactly.  That's the telling argument for a single VCS-independent
action stamp, right there.  And props to you for taking the (correctly)
long view of the matter!

I'm not real happy about the action stamps being so long as it is.
Unfortunately, they're the shortest thing I've managed to come up with
that has the required properties of being unique and self-describing.

> PS.  In that 1985 example, the email address jimb@redhat.com is
> ahistorical, as Red Hat didn't exist in 1985.  That info is taken
> straight from the current bzr repository.  Most likely the
> repository was made ahistorical during an earlier conversion,
> unfortunately.

Yes, and that sort of ahistoricity was unavoidable for the simple
reason that DVCSes need email addresses as Internet-global
credentials.  The act of mapping CVS usernames to these therefore
almost necessarily introduces anachronisms.

Repository translation is *difficult*.  At least, doing a non-half-assed 
job of it is.  The tradeoffs between usability and historicity don't
have easy or pat answers.

It's especially difficult for a project as steeped in history - nay,
positively encrusted with it - as Emacs.  This is already the hairiest
conversion I've ever done, measured by complexity of the lift file,
and it's going to get much worse before it's done.  I don't expect to
ever see a messier one.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Sean Sieger]

    After enough pissy, semi-autistic territorial
    grunting I just start tuning all of it out.

No, no.  The only pissing on any ground is *your* pissing on the edges
of ground you seem only to be guessing at as to the ground's actual
existence.  And, you have only ever attenuated your attention from the
very beginning of your hegemonic effort.  Eric.  Hegemony works best
that way.

    Or, you can leave me to do all the work alone while flaming from the
    sidelines. If you choose that, don't blame anyone but yourselves
    if you think (wrongly) that you've had no influence on the result.

Your heroism is blinding.

Re: Repo cpnversion progress report

[Sean Sieger]

No, no.  The only pissing on any ground is *your* pissing on the edges
of ground you seem only to be guessing at as to the ground's actual
existence.  And, you have only ever attenuated your attention from the
very beginning of your hegemonic effort.  Eric.  Hegemony works best
that way.

    Or, you can leave me to do all the work alone while flaming from the
    sidelines. If you choose that, don't blame anyone but yourselves
    if you think (wrongly) that you've had no influence on the result.

Your heroism is blinding.

Re: Repo cpnversion progress report

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > I hear the argument about forensics, but the Bazaar revision numbers
> > are no more helpful for that than the action stamps. If anything,
> > spelunking is an argument for appending those numbers to the change
> > comment of each revision - leaving them in as references would a
> > bass-ackwards approach to the problem.
> 
> Moving the "equiv to bzr r123456" to the commit message of that
> corresponding Git commit sounds like an good compromise.  Of course, we
> don't need it for every commit, but for all those commits that have
> a corresponding "action stamp".

Technically, I could do this.  It would take a minor extension of
reposurgeon, but that is in itself OK because I'm going to have to
build that same primitive to do the thing Eli Zaretskii wanted
(fixes-bugs headers folded into the commit comments).

Let me explain this; it will give some insight into my working methods.
The primitive I plan to add to reposurgeon will be called "append"
or some verb like that.  It will take two arguments; one commit 
identifier, one string.  The effect will be to append the specified
line to the specifed commit comment.

Then, I would extract a list of revisions to be marked from my master
FOSSILS file and compile it into a sequence of append commands.  So, for
ecample, this association:

	100984 -> 2010-08-05T23:34:12Z!dann@ics.uci.edu

would compile to this append command:

<2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nBazaar revision 100984"

For Eli's feature, I would build a map from revisions to fixes-bug numbers
by mechanically analyzing the output of bzr log, then generating append
commands like this:

<2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nFixes bug 2317"

All these append commands would be appended to the lift script to be
applied on conversion day.

These things can be done.  The question is whether they *should* be done.
Because with each benefit there also comes a cost.

There is a real cost to burdening the commit comments with an
ever-increasing load of fossil data.  As Paul Eggert pointed out in
connection with references, this will scale badly over time.
Additionally, while none of these processing steps (or many others like
them) are difficult in principle, they accumulate to a huge load
of work for me.

Accordingly, I want to hear a use-case analysis.  That is, rather than
relatively vague hand-waving about forensics I want somebody with a
stake in the process *other than me* to lay out a set of user stories
about what kinds of navigation and lookup we want to support, so that
potential data representations (map file, in-commit comments, etc.)
can be checked against those stories.

Here's an example of a user story:  Someone is reading the emacs-devel 
archives and reads mail containing a reference to an Emacs change by 
Bazaar revision.  How does he get to the corresponding git revision?

What other user stories are there?  What do they tell us about 
acceptable gradients in lookup costs?  What does that tell us 
about good metadata representations?

I think I know what many of the conclusions will look like.  I've
been around this track before!  But others might educate me, and
will certainly educate some of the rest of you.

> > But there's a better way.  We're going to have a complete
> > revision-to-action-stamp map as part of the record.  It would be
> > pretty easy to write Emacs code that uses that map to find revisions
> > by Bazaar reference number.  That's the right solution, IMO.
> 
> But where would this map be stored?

/etc, same as any other static data used by a mode.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Jan D.]

Hi. 


> 31 jan 2014 kl. 22:51 skrev "Eric S. Raymond" <esr@thyrsus.com>:
> 
> Here's an example of a user story:  Someone is reading the emacs-devel 
> archives and reads mail containing a reference to an Emacs change by 
> Bazaar revision.  How does he get to the corresponding git revision?
> 
> What other user stories are there? 

Somebody looking up a bug report containing a reference. 
This is not uncommon.

     Jan D. 

Re: Repo cpnversion progress report

[Stefan Monnier]

> <2010-08-05T23:34:12Z!dann@ics.uci.edu> append "\nFixes bug 2317"

(with-nitpick-mode
 Should be "\nFixes bug#2317")

> There is a real cost to burdening the commit comments with an
> ever-increasing load of fossil data.  As Paul Eggert pointed out in
> connection with references, this will scale badly over time.

For the "Fixes bug#NNN", this cost is not does not accumulate: it was
there already and we just translate it in another form.

For the references, it is true that they can accumulate.  But we
shouldn't say "Bazaar revision NNNN; CVS revision 1.MM; RCS revision 1.PP".
Instead we should only keep the original reference text (in the above
case it would be "RCS 1.PP"), so they don't accumulate either.

> Additionally, while none of these processing steps (or many others like
> them) are difficult in principle, they accumulate to a huge load
> of work for me.

To reduce the load, you can just skip the "conversion to action stamps".
I think it's more important to preserve their correctness (i.e. not
touch them) than to make them easy to use.

> Accordingly, I want to hear a use-case analysis.  That is, rather than
> relatively vague hand-waving about forensics I want somebody with a
> stake in the process *other than me* to lay out a set of user stories
> about what kinds of navigation and lookup we want to support, so that
> potential data representations (map file, in-commit comments, etc.)
> can be checked against those stories.

I know I won't be using any external data file because I need such
a thing rarely enough that I won't remember where the file is or which
command to use for that.

Also they're rare enough that it's OK if it takes a while to figure out
what it's referring to.

> Here's an example of a user story:  Someone is reading the emacs-devel
> archives and reads mail containing a reference to an Emacs change by
> Bazaar revision.  How does he get to the corresponding git revision?

He doesn't and moves on.  Or he goes back to the old Bzr repository to
figure it out.

For fixes it's very different.  The way it works is: vc-annotate tells
me the code was changed in commit NNNN and that commit says it's linked
to bug#MMMM so I go check bug#MMMM to try and understand why the code is
the way it is.  This is a fairly common occurrence, and it's common to
use the bug#NNNN reference as an "excuse" to keep the commit log
shorter, so it's important to preserve this info.


        Stefan

Re: Repo cpnversion progress report

[Paul Eggert]

Eric S. Raymond wrote:
> I'm not real happy about the action stamps being so long as it is.

How about a POSIX timestamp rather than an ISO 8601 string? 
"1391204651!larsi@gnus.org", for example, instead of 
"2014-01-31T21:44:11!larsi@gnus.org".  Although it's just 9 characters 
difference, the savings add up when you're trying to read a screenful of 
these things.

The ISO 8601 string is not that readable, nor does it match the 
localtime clock of committer, so it's a bit of a magic cookie anyway.

As I understand it the first glimmer of Emacs in RMS's eye was circa 
1972, so even if we magically resurrected his original code the 
timestamps would never need to be negative.  We could say that 
time-since-1970 is "Emacs time".

Re: Repo cpnversion progress report

[Juanma Barranquero]

On Sat, Feb 1, 2014 at 1:05 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> The ISO 8601 string is not that readable

I find it perfectly readable.

>, nor does it match the localtime
> clock of committer

For some of us is close enough, and anyway it is a fixed offset
(modulo DST) from your local time, so it is not opaque or a magic
cookie at all.

     J

Re: Repo cpnversion progress report

[Eric S. Raymond]

Paul Eggert <eggert@cs.ucla.edu>:
> Eric S. Raymond wrote:
> >I'm not real happy about the action stamps being so long as it is.
> 
> How about a POSIX timestamp rather than an ISO 8601 string?
> "1391204651!larsi@gnus.org", for example, instead of
> "2014-01-31T21:44:11!larsi@gnus.org".  Although it's just 9
> characters difference, the savings add up when you're trying to read
> a screenful of these things.

Clever hack!  I really, really liked this idea - for about thirty seconds.

Then I remembered, dammit, that I have run into a fair amount of
confusion over whether that kind of Unix time is based on a UTC or
local epoch.  That's why the Z in RFC3339 date format is functional; it 
pins the stamp to Zulu time. 

Yes, I know POSIX time is supposed to be seconds UTC (sort of, modulo
leap seconds).  People get confused anyway - in fact I remember a
Linux distribution that actually gave you an installation choice about
whether to keep your integer timestamps in local or in UTC a la POSIX.  I 
boggled.

If we leave this ambiguous in the representation, someone in the
future will curse us.  And not without reason.  Because even if they
know the right UTC-based interpretation of Unix time, they have no way
to be sure everyone who touched the data *before* them did.

(Wearing my GPSD maintainer hat I have to deal with crap like this a lot.)

More generally, we'd lose the self-describing property. It's hard to look 
at an RFC3339 timestamp and not know what it is.  Not so much with an integer
literal.

So yes, a clever hack.  But, alas.  Not, I fear, a good one.

If we really had to deal with screenfulls of these things the tradeoff
might potentially be different.  That actually happened in the change
comments of the NUT project. Not here, though.  The worst case I've
seen in the Emacs history is two of them per line, one pair per
commit message or ChangeLog entry.

> As I understand it the first glimmer of Emacs in RMS's eye was circa
> 1972, so even if we magically resurrected his original code the
> timestamps would never need to be negative.  We could say that
> time-since-1970 is "Emacs time".

Ha.  You know what popped into my head when I read that last?  "1970
is as old as the world."

Text Editors in The Lord of the Rings

http://crookedtimber.org/2011/07/30/text-editors-in-the-lord-of-the-rings/

Emacs: Fangorn

    Vast, ancient, gnarled and mostly impenetrable, tended by a small band
    of shepherds old as the world itself, under the command of their
    leader, Neckbeard. They possess unbelievable strength, are
    infuriatingly slow, and their land is entirely devoid of women. It
    takes forever to say anything in their strange, rumbling language.

When I read that, I do not mind telling you that I felt my age. :-)

I've been thinking about that satire a lot lately.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Eric S. Raymond]

Jan D. <jan.h.d@swipnet.se>:
> > What other user stories are there? 
> 
> Somebody looking up a bug report containing a reference. 
> This is not uncommon.

Yeah, that's a good one.  I'll start keeping a list.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> To reduce the load, you can just skip the "conversion to action stamps".

I've already paid the time and complexity cost for that.  There's not
really a savings there.

> For fixes it's very different.  The way it works is: vc-annotate tells
> me the code was changed in commit NNNN and that commit says it's linked
> to bug#MMMM so I go check bug#MMMM to try and understand why the code is
> the way it is.  This is a fairly common occurrence, and it's common to
> use the bug#NNNN reference as an "excuse" to keep the commit log
> shorter, so it's important to preserve this info.

I agree. This goes on the list of use cases that needs to be supported
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Repo cpnversion progress report

[Eli Zaretskii]

> Date: Fri, 31 Jan 2014 16:05:49 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> How about a POSIX timestamp rather than an ISO 8601 string? 
> "1391204651!larsi@gnus.org", for example, instead of 
> "2014-01-31T21:44:11!larsi@gnus.org".

Please don't.  These strings are for human consumption.
"2014-01-31T21:44:11" is easily parsed by humans, while "1391204651"
needs some program to convert it to human-readable time stamp.  If you
look at this text outside of Emacs, the conversion is not easy, and
even inside Emacs it needs to type a command, which is a nuisance.

> The ISO 8601 string is not that readable, nor does it match the 
> localtime clock of committer, so it's a bit of a magic cookie anyway.

It's a magic cookie which is easily interpreted by simply reading it.

Re: Repo cpnversion progress report

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Juanma Barranquero <lekktu@gmail.com>:
>> Well, do you at least agree with him when he says
>> 
>> > I'm ignored already.  You never accepted any argument of mine through
>> > that long and tiresome "discussion".  You are always right and all
>> > those who disagree with you are always wrong.
>> 
>> and
>> 
>> > I never had any influence over that, because you refuse to listen
>> > to any dissenting arguments, and prefer to stubbornly do what you
>> > decided was right ahead of any discussion.
>
> Sigh.  I wasn't going to go there, but....in fact I have already done
> several work items raised specifically by Eli.

That's not my impression.  My impression is that you repeatedly
pronounce having cleared a self-set bar and when people including Eli
point out where you didn't, you make them accountable for setting the
bar.

Unless your plan involved bullshitting everybody including yourself
about the quality of the achieved solution, there is no point in
shouting down those who point out where you don't meet your goals.

If the ultimate transition is to involve history rewriting involving a
change of the existing Git commit ids, and that's the setup you are
aiming for partly in order to get a nice showcase for your repo surgeon,
then any remaining deficiency is going to be permanent.

> I'm a very reasonable person about meeting requirements like that
> which are raised in a genuine attempt to improve the quality of the
> result. It's for sure no one else is going to do them for you.

You'll find that a lot of people have done a lot more work on Emacs than
you did, so it is disingenuous to suggest that there is no alternative
to letting you have your way.  There actually has been a working Git
mirror for quite a few years that was set up (and restarted from scratch
several times in its infancy) and used without your input.  So there
clearly _are_ people who have experience in that area, and it's also
obvious from the exchanges that there are people who have more knowledge
about the kind of labels and references that are in use than you were
able to imagine.

Locking out their feedback might speed up the time until you are able to
declare having finished your task.  But it does not help with you being
on top of it.

> Being reasonable does not, however, mean I will put up with
> obstreperous bullshit.  What I just quoted, from Juanma and Eli both,
> was obstreperous bullshit.  That, I respond to by decreasing my
> willingness to pay attention to the bullshitter.
>
> So let me spell it out: Juanma, if you think you are not being
> listened to, you have only your own bad attitude to blame for that.
> Same goes for you, Eli. After enough pissy, semi-autistic territorial
> grunting I just start tuning all of it out.

There are several perfectly viable solutions that get along without
rewriting the commit history of the existing mirror, by collecting the
respective information in plain files and/or Git labels and/or Git
notes.  Since they work without rewriting, they can be improved and/or
fixed over the course of time.  Consequently, they don't require the
kind of "everything has to be perfect at first try" mind frame that your
preferred solution is built around and that you are sabotaging
confidence in yourself by locking out feedback.

Voting for an "everything has to be perfect at first try" solution
requires a trust in the solution that is hard to achieve when you turn
it into a one-man show in the face of those who are actual permanent and
active contributors to the project.

> Conversely, you can earn my attention and increased willingness to do
> what you want by putting effort into helping with the work.

"to do what you want"?  I don't think that's an accurate
characterization.  Eli does not want to migrate to Git.  He is not
trying to make you "do what he wants" when he points out where your
claims fall flat.  He is helping you doing what _you_ want if he raises
his objections in a timely and detailed manner where you are able to
address them.

The nature of a history rewrite does not make it feasible to address
them once the conversion is done, and you have made abundantly clear
anyway that you only have a limited time window to bother with the
conversion and followup.

If the quality of the conversion will be such that one will have to
revert to auxiliary tools and files created after the conversion to
resolve a sizable number of repository-based questions, then it might be
easier to just continue reusing the existing mirror together with the
auxiliary tools and files one will need anyway.

So if you want Emacs to be a showcase for your toolset and skills, you
better figure in its existing community in your plans to make a
convincing pitch.

-- 
David Kastrup

Re: Repo cpnversion progress report

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 31 Jan 2014 18:16:25 -0500
> Cc: Karl Fogel <kfogel@red-bean.com>, Eli Zaretskii <eliz@gnu.org>,
> 	emacs-devel@gnu.org
> 
> I know I won't be using any external data file because I need such
> a thing rarely enough that I won't remember where the file is or which
> command to use for that.
> 
> Also they're rare enough that it's OK if it takes a while to figure out
> what it's referring to.
> 
> > Here's an example of a user story:  Someone is reading the emacs-devel
> > archives and reads mail containing a reference to an Emacs change by
> > Bazaar revision.  How does he get to the corresponding git revision?
> 
> He doesn't and moves on.  Or he goes back to the old Bzr repository to
> figure it out.

We could have a VC command that consults an external file with the
mapping.  We could even display the results of such mapping in a
tooltip or in a display property.  Then the need to remember will
disappear.

I do agree (and thought so from the get-go) that conversion of old
revision references to time stamps is a lot of effort for little gain.

Re: Repo cpnversion progress report

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      He
    even continued saying this after it was obvious that Bazaar was not in
    any meaningful sense a GNU project.

There is only one GNU Project.  Bazaar was and is a GNU package.
It is a GNU package because I dubbed it one -- like every other
GNU package.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Repo cpnversion progress report

[Stefan Monnier]

>> He doesn't and moves on.  Or he goes back to the old Bzr repository to
>> figure it out.
> We could have a VC command that consults an external file with the
> mapping.  We could even display the results of such mapping in a
> tooltip or in a display property.  Then the need to remember will
> disappear.

And then arrange for that extra code to be triggered only for the case
we're looking at an Emacs revision?  Sounds difficult/impossible.
We'll need some explicit user action.  "over-engineering" is the word
that comes to mind.


        Stefan

Re: Repo cpnversion progress report

[Stefan Monnier]

> How about a POSIX timestamp rather than an ISO 8601 string?
> "1391204651!larsi@gnus.org", for example, instead of

We could also use some kind of huffman encoding, to save yet more characters.


        Stefan "seriously, let's try to keep those beasts semi-readable,
                please"

Re: Repo cpnversion progress report

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> >> He doesn't and moves on.  Or he goes back to the old Bzr repository to
> >> figure it out.
> > We could have a VC command that consults an external file with the
> > mapping.  We could even display the results of such mapping in a
> > tooltip or in a display property.  Then the need to remember will
> > disappear.
> 
> And then arrange for that extra code to be triggered only for the case
> we're looking at an Emacs revision?  Sounds difficult/impossible.
> We'll need some explicit user action.  "over-engineering" is the word
> that comes to mind.

100% with Stefan on this.  IMO it's not so common a use case that
heroic measures are required.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>