On Wed, Sep 18, 2019 at 9:10 AM Christoph Hertzberg < [email protected]> wrote:
> I guess the main decision left is to decide on a schedule when to > officially switch to gitlab and if/how long we will keep the bitbucket > repository as a mirror (or essentially as a snapshot) > What about trying to sync it with new releases, e.g.: - Releasing a 3.3.x within a few days and take this opportunity to announce the migration to Gitlab.com on the "...". - Do the migration. - Release 3.4-beta right after to celebrate the migration. Maybe we could target the 8 of October? This should give us enough time to fix the very few true 3.4 blockers. We also need to create a group for Eigen on gitlab.com, since "eigen" is already taken (and I got no answer from the owner despite one reminder), we have to chose something else. On github, I created "eigenteam" to hold the current git-mirror, but we can think of: - eigenteam - eigen-team - eigenlib - libeigen - eigen-official I think that keeping the current hg repository sync with the new git repo is going to be a nightmare (because we rewrote the history), so I would probably keep it as a snapshot (unless someone come up we a working solution). This also remind me that we'll have to do something about this git-mirror. We can either: (1) - make it empty with a link to the new git repo (2) - keep it as is (i.e., no sync) for a short period and then proceed as (1) (3) - delete it and recreate it as a synced mirror of the new repo, and then after a short period proceed as (1) If I'm not mistaken option (3) will probably break all users of this mirror, so that's probably not the best option! Once bitbucket closes hg-support (or sooner), we can replace our current > main-repo by an otherwise empty git repository which just links to the > new repository (or make a git-mirror, but I don't see any benefits here). > good idea for the empty git repo. > Also, we should probably host the "last official" state of the mercurial > repository somewhere (as read-only). > sure. gael > > Christoph > > > On 18/09/2019 00.30, Gael Guennebaud wrote: > > Thanks to Joseph's work, and after fighting with Gitlab.com's super > > aggressive spam filter, I finally managed to get the following Gitlab.com > > project as a demo of what could be the outcome of a full migration: > > > > https://gitlab.com/ggael/eigen-migration6 > > > > This project includes: > > - a git repo with bug ids, commit hashes, and pull-request links > updated > > in commit message. > > - a migration of all our bugzilla entries and comments with similar > > updates as the commit messages. > > > > Some examples: > > - attachments, links to commits and bugs: > > https://gitlab.com/ggael/eigen-migration6/issues/1305 > > - link to PR: > > https://gitlab.com/ggael/eigen-migration6/issues/1306#note_218167101 > > - migration of our "3.x" bug entries as milestones: > > https://gitlab.com/ggael/eigen-migration6/-/milestones/6 > > - link to PR from commits: > > > https://gitlab.com/ggael/eigen-migration6/commit/97f1e1d89ff759186f4a9c866f7ea3afa7b4c325 > > - link to bug from commits: > > > https://gitlab.com/ggael/eigen-migration6/commit/c06e6fd115d747c42a2b2ea029c53bbdf41276d6 > > > > The bugzilla to gitlab migration script is there: > > https://gitlab.com/ggael/bztogl (adapted from > > https://gitlab.gnome.org/World/bztogl) > > > > PS1: If you notice many extra newlines in issue descriptions/comments, > > that's normal, I already fixed this shortcoming. > > > > What do you think ? > > > > gael > > > > > > > > On Wed, Sep 11, 2019 at 6:03 PM Gael Guennebaud < > [email protected]> > > wrote: > > > >> 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 > >> > >> > >> > > > > -- > Dr.-Ing. Christoph Hertzberg > > Besuchsadresse der Nebengeschäftsstelle: > DFKI GmbH > Robotics Innovation Center > Robert-Hooke-Straße 5 > 28359 Bremen, Germany > > Postadresse der Hauptgeschäftsstelle Standort Bremen: > DFKI GmbH > Robotics Innovation Center > Robert-Hooke-Straße 1 > 28359 Bremen, Germany > > Tel.: +49 421 178 45-4021 > Zentrale: +49 421 178 45-0 > E-Mail: [email protected] > > Weitere Informationen: http://www.dfki.de/robotik > ------------------------------------------------------------- > Deutsches Forschungszentrum für Künstliche Intelligenz GmbH > Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany > > Geschäftsführung: > Prof. Dr. Jana Koehler (Vorsitzende) > Dr. Walter Olthoff > > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > Amtsgericht Kaiserslautern, HRB 2313 > ------------------------------------------------------------- > > >
