Hi Bram, sorry for the late reply. I'm pretty busy and also needed a bit to find the proper words. It also takes some time to get into this topic again after several months of silence.
Am Samstag, 8. August 2015, 21:43:13 schrieb Bram Moolenaar: > > Markus Heidelberg wrote: > > > For me, a proper project history from developer view is equal to good > > documentation from user view. > > It's been some since we looked at this, and the information is now > scattered over several messages. > > Markus, could you make the step-by-step description of what needs to be > done? I need exact steps and some hints about what to do when there are > errors. My proposal was: 1. Cleanup in the HG repository 2. Conversion from HG to Git 3. Cleanup in the Git repository +++ In detail: +++ 1. Cleanup in the HG repository ******************************* This is covered by the existing HG cleanup script. Attached again because compared to the latest version Christian sent today, I've added a check whether the rebase extension is enabled. Basically it does two things: - close the unused or invalid branches - fix and complete the tags My test runs I performed like this: # copy the original HG repository cp -a vim-hg vim-hg-copy # clone the copy hg clone vim-hg-copy vim-hg-copycloned # run the cleanup script cd vim-hg-copycloned sh ../cleanup/hg-cleanup.sh # push back from the cloned copy to the initial copy to verify that no # history has been rewritten, elsewise this command would fail hg push # verify the result manually with "hgk" or "hg log", compare with the # original repository cd ../vim-hg-copy hgk hg log --style compact --graph I don't expect errors, so I can't predict what to do when any will occur. Just ask in that case. 2. Conversion from HG to Git **************************** > I do intend to use the "export to github" feature of the Google code > site, so that (hopefully) issues will be deep-linked to their new place. > I do assume that after the Mercurial repository is converted to git, we > could just wipe it out and replace it with another. What does "issues deep-linking" mean exactly? Automatically redirecting from an issue URL on the old Google site to an issue URL on the new GitHub site? I don't know about the dimension of "In the future, the page will automatically redirect to well-known project hosting services" from the Exporter FAQ [1], but it sounds neither are you sure about this topic. On the other side, is this redirection really that important? [1] https://code.google.com/p/support-tools/wiki/GitHubExporterFAQ I tested the "Export to GitHub" button today. I saw the drawbacks with issues conversion, which you already mentioned in another mail, i.e. the original author and date information is only added in the comment. Obviously it is not possible to make a relation from a Google user to a GitHub user. The problem with the date is that the GitHub API is used for importing, which always uses the current time of course. I don't know which script runs in the background for repository conversion, but it does not create a completely valid result. I had already seen this problem in your Git test repository, a local conversion with the hg-fast-export scripts worked properly and this is the way I'd go. The problems in the repository after online conversion: - There are 3 history roots instead of just 1, the branches do start without parent instead of branching off from a particular commit. - The merge parents of the two merge commits are in the wrong and logically less correct order (compare with "git log --graph"). - The clone is several hundreds MB big, it seems the repository is not repacked after conversion. Strange, I wonder why this hasn't been fixed yet. After the repack, it is only 40 MB. 3. Cleanup in the Git repository ******************************** There were suggestions to use the Git mirror from vim-jp as base for the official repository, don't know if this is still an option. Of course this cleanup step, which required history rewrite, would have to be omitted in that case and I see hardly any benefit in using vim-jp's repo. I won't repeat the cleanup options in the state we are now, but leave it for after having finished the first step. +++ End of details +++ > I would rather not take the risk of messing up the Mercurial repository. > Thus would the best approach be to do the conversion locally and replace > the git repository on github? We could even try that out now, since the > github repository is for testing anyway. I invested quite a bit of time and I'm not eager to change the HG cleanup into a Git cleanup, having lots of the spent time wasted. The cleanup script runs locally on your local repository as described above. There is nothing, which can be messed up without being able to recognize it in the result before publishing. And as Christian wrote, it can always be fixed in case some mess gets published. But the script won't mess up anything in the first place. #!/bin/sh # Vim HG repository cleanup hg config extensions.rebase || (echo -e "Rebase extension has to be enabled in ~/.hgrc:\n[extensions]\nrebase =" && exit 1) # close stale branches, switch back to default branch afterwards # This has the slightly bad visual side-effect of parallel development from the # previous branch head up to the corresponding closing commit in "hg log # --graph", but is the correct thing to do to avoid seemingly active branches # showing up in "hg branches" output. hg update -C vim hg commit --close-branch -m"Close invalid branch 'vim'" hg update -C vim72 hg commit --close-branch -m"Close unused branch 'vim72'" hg update -C vim73 hg commit --close-branch -m"Close old branch 'vim73'" hg update -C default # remove unused branch lines # However, since the network protocol works append-only, you cannot push it # to the public repo. This would have to be done directly on the server via SSH # or an admin interface. # And still this change would have no effect when pulling from existing # clones, it would have to be stripped there as well, so ignore this step. #hg strip vim #hg strip vim72 # find potentially wrong tags by checking whether the patch number had been # added to src/version.c in that changeset #for i in $(hg tags | grep -o "v7-.*-[^ ]*"); do hg diff -c $i src/version.c | grep -q "^+ $(echo $i | sed -e 's/v7-.*-0*//')," || echo $i; done # result: # v7-4-415 # v7-4b-000 # v7-3-523 # v7-3-143 # v7-2-446 # v7-2-443 # v7-2-442 # v7-2-441 # v7-2-440 # v7-2-439 # v7-2-438 # v7-2-437 # v7-2-436 # v7-2-232 # v7-2-176 # v7-2-167fix # v7-2-168 # v7-2-082 # v7-2-080 # v7-2-000 # v7-2c-000 # v7-2b-000 # v7-2a-00 # v7-1-258 # v7-1-008 # v7-0-225 # determine the actually wrong tags after manual inspection # v7-4-415 # v7-2-446 # v7-2-443 # v7-2-442 # v7-2-441 # v7-2-440 # v7-2-439 # v7-2-438 # v7-2-437 # v7-2-436 # v7-2-232 # v7-2-176 # v7-2-167fix # v7-2-168 # v7-2-082 # v7-2-080 # v7-1-008 # v7-0-225 # fix the wrong tags # Do not edit the .hgtags file manually, but rely on "hg tag" to do the right # thing, see # http://mercurial.selenic.com/wiki/Tag # http://mercurial.selenic.com/wiki/TagDesign hg tag -f --local rebasedest hg tag -f -r 2ec8266fa254f9f90fd302df275d2813ae08a8e6 v7-0-225 hg tag -f -r 042fa969dab175d414d611425d8a61424bacf75f v7-1-008 hg tag -f -r 12cecc379574aba2231cbba54c4eaeef3432db69 v7-2-080 hg tag -f -r be7491f23e9d8818821de61d9ce53cb1cb1c7dc9 v7-2-082 hg tag -f -r ad41c6afaa7b0b512cd97dd07a93cc0504508227 v7-2-168 hg tag -f -r e8eeeff19eae568f4642cb9f368a1aec6c749a61 v7-2-176 hg tag -f -r 5bd06a91c65c06847fb0d618c71736d7c73e95d2 v7-2-232 hg tag -f -r e12b9d992389cc770eb72e16932313cd0905190f v7-2-436 hg tag -f -r ecb9c2b70b0f6e9918e75bf4e1ac887748a2313a v7-2-437 hg tag -f -r d44112feb8153ffaa6ab8ec6442c5c4af0951728 v7-2-438 hg tag -f -r ea7c2d89b76bf42eb0da3459e8813104d76bca02 v7-2-439 hg tag -f -r cd6e6876308e4e0fb621431646ebeec4b49a2504 v7-2-440 hg tag -f -r f838615313cd5832efa624526a7575668fb40da9 v7-2-441 hg tag -f -r b0ebf9d121ff99eb2e1697a35dca528e7ecb8f4c v7-2-442 hg tag -f -r 0c1e413c32f1f3f8e28ebf8a030cedeeb664cd46 v7-2-443 hg tag -f -r b619655b31db9469f6fe41932daff7a566079097 v7-2-446 hg tag -f -r 353442863d8558dc89d35ef349b60ebb2e38de0e v7-4-415 hg tag -r v7-2-167fix v7-2-167 hg tag --remove v7-2-167fix # Optionally squash all separate tag changing commits into one # with a proper description cat <<EOF > logfile.txt Fix wrong tags v7-2-167fix has been renamed to v7-2-167 because the state in repository matched version 7.2.167. The others have been moved to the correct changeset. EOF hg rebase --dest rebasedest --source tip~18 --collapse --logfile logfile.txt rm logfile.txt # remove unused tag hg tag -m"Remove unused tag from invalid line of history" --remove start # add missing tags hg tag -f --local rebasedest hg tag -r f03c3fae0a99 v7-0-076 hg tag -r v7-2-000 v7-2 hg tag -r ee53a39d5896 v7-3 hg tag -r f0915ae869cf v7-3-001 hg tag -r 2e72d84e8965 v7-3-139 hg tag -r 96a7b564c2f3 v7-3-140 hg tag -r 0d201adaf9c5 v7-3-141 # The following tags could not be created because the changeset is combined # with the changeset of the subsequent patch: v7-1-083 v7-2-054 # Optionally squash all separate tag adding commits into one # with a proper description hg rebase --dest rebasedest --source tip~6 --collapse -m"Add missing tags" # cleanup hg tag --local --remove rebasedest -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
