|
To summarize what is missing:
- there are a lot of "backporting rev[0-9]+" that are not found.
I don't know what "backporting" means. I just know that "hg log
--rev N" for all the one I tested returns "unknown revision".
I guess I could fix most of them by adding some of the main
developers remote (remote in git sense). This would work only if
the same run of fast-export converts all Eigen mercurial repos at
once and then everyone picks its own git parts from this. Using a
map of hg->git hashes should allow us to rebuild the individual
git repos automatically.
- I do not catch ranges of revision number like "[0-9]+-[0-9]+".
It wouldn't be hard to achieve.
- what about unamed hg heads ? Should we drop them ? If not, I
would appreciate if someone knowing mercurial could name them
(with a name valid for hg and git).
Joseph
Le 12/09/2019 à 00:37, Gael Guennebaud
a écrit :
Dear Eigen developers,
- I can convert all reference like to revisions or mercurial
hashes that
follows the regex in [2].
gael
- I did not try to convert URLs although it should not be
hard.
- I manually edited the author file [5] so that they would
fit git
author format. If you find yourself in the list and want to
update it,
you can contact me.
It should not be hard to add more rules to the plugin
convert_references
if anyone feels like doing it.
Best,
Joseph
[1] https://github.com/frej/fast-export.git
[2]
https://github.com/jmirabel/fast-export/blob/1fdc76e0626acd6adfcc0d900d14f36b459c4798/plugins/convert_references/__init__.py#L16
[3] https://github.com/jmirabel/fast-export
[4] https://github.com/jmirabel/eigen_tmp.git
[5]
https://github.com/jmirabel/fast-export/blob/master/eigen/authors_reworked
Le 11/09/2019 à 18:03, Gael Guennebaud a écrit :
> To prepare the migration from bitbucket, I started to
play a bit with
> its API to see what could be done. So far I've quickly
draft two
> (ugly) python scripts to archive the forks and
pull-requests. Since
> this is a one shot for us, I did not cared about
robustness, safety,
> generality, beauty, etc.
>
> You can see them there
> : https://gitlab.com/ggael/bitbucket-migration-tools and
contribute!
>
> ** Forks **
>
> You can see the summary of the fork script
> there: http://manao.inria.fr/eigen_tmp/archive_forks_log.html
>
> The hg clones (history+checkout) represents 20GB, maybe
12GB if we
> remove the checkouts. Among the 460 forks, 214 seems to
have no change
> at all (according to "hg out") and could be dropped. I
don't know yet
> where to host them though.
>
> This script can be ran incrementally.
>
>
> ** Pull-Requests **
>
> You can find the output of the pull-requests script
> there: http://manao.inria.fr/eigen_tmp/pullrequests/
>
> There is a short summary, and then for each PR a static
.html file
> plus diff/patch files, and other details. For instance,
> see: http://manao.inria.fr/eigen_tmp/pullrequests/OPEN/686/pr686.html
>
> Currently this script cannot be ran incrementally. You
have to run it
> just before closing the respective repository!
>
> Also, this script does not grab inline comments. Only
the main
> discussions is archived. Those can be obtained by
iterating over the
> "activity" pages, but I don't think that's worth the
effort because
> they would be difficult to exploit anyway.
>
>
> ** hg to git **
>
> As discussed in the other thread, if we switch from hg
to git, then
> all hashes will have to be updated. Generating a map
file is easy, and
> thus updating the links/hashes in bug comments and PR
comments should
> not be too difficult (we only have to figure out the
right regex to
> catch all variants).
>
> However, updating the hashes within the commit messages
will require
> to rewrite the whole history in a careful order. Does
anyone here
> feels brave enough to write such a script? If not, I
guess we could
> live with an online php script doing the hash
conversion on demand. I
> don't think we'll have to follow such hashes so
frequently.
>
> cheers,
> gael
>
>
|