Re: [eigen] Bitbucket migration

On Thu, Sep 12, 2019 at 12:59 AM David Tellenbach <david.tellenbach@xxxxxxxxxxxxx> wrote:

But is it our responsibility to archive such forks? There could be forks for personal purpose only with no intend to create a PR at all. Should we really bother to archive these? (At least) everyone with a mercurial repo on bitbucket has received an email that mercurial support will be dropped. If someone thinks his fork is worth keeping, the person should archive it or open a PR. I think the keeping the changesets of all PRs is enough.

We're talking about open-source code. IMO this should be the responsibility of bitbucket to keep them read-only for a few more years. Anyways, I already have them archived on my computer, so that's a minor aspect. Let's focus on the other ones.

> ** Pull-Requests **

Does gitlab allow to map "[Bb]ug (\d+)" to (an archive of) our bugzilla
page and "\#(\d+)" to either the archived old PRs or new PRs/issues? (if
need be, we could manually create issues #1 to #7xx with just a link to
the archived PRs.

I haven't check that yet.

If there's no possibility to automatically forward Bugs/PRs, it should again be possible to create those automatically using the GitLab API.

In gitlab issues are referenced with #123 and merge-requests with !123 (see https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references)

So when switching from hg to git, we could do: "([Bb]ug) (\d+)" -> "\2 #\1" in the commit messages. For bug comments, this change is already taken care by the bz2gitlab migration script.

For old pullrequests, it is possible to automatically link WHATEVER-XYZ to https://some_url/XYZ via the "custom issue tracker" service. Demo: https://gitlab.inria.fr/guenneba/eigen-bzmigration-test2/issues/1#note_234549

So we could rewrite old PR references as PR-XYZ. One shortcoming though is that you cannot configure what "WHATEVER" is. The underlying matching regex seems to be as general as: "[a-zA-Z]-(\d+)". Still ok I guess.

Another topic: How about creating a gitlab.com group (since eigen is taken I suggest eigen-official) and create a migration repo where we host all the migration stuff and scripts?

I've asked the owner of gitlab.com/eigen last week to see if he would be super kind to release the "eigen" username for us (as it seems to be used by himself only), but no answer yet. Without a positive answer we could think about:

eigen-official

eigen-team

libeigen

gael

David

On 11. Sep 2019, at 23:27, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On Wed, Sep 11, 2019 at 6:50 PM Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

> ** 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.

I think it is sufficient if we host a (frozen) version of the main
repository (probably simply at tuxfamily). I think many forks don't have
changes, because they actually got merged.
And I don't think we need to host any of the forks, as long as we have
the changesets in the archived PRs.

I don't think all forks with changes have a related PRs, but forks exhibiting changes and that are associated to a close PR can probably be ignored too.

> ** Pull-Requests **

Does gitlab allow to map "[Bb]ug (\d+)" to (an archive of) our bugzilla
page and "\#(\d+)" to either the archived old PRs or new PRs/issues? (if
need be, we could manually create issues #1 to #7xx with just a link to
the archived PRs.

I haven't check that yet.

Did we actually plan to migrate bugzilla to gitlab-issues as well?
Would we do this by just creating new issues with a link to the
bz-archive? (This would be only slightly inconvenient if discussions are
split, but that's ok, IMO)

See this first attempt: https://gitlab.inria.fr/guenneba/eigen-bzmigration-test1/issues
Almost everything is preserved including the bug's ID. We can also automatically mark the bz bugs as "MOVED" with a link to the respective gitlab entry.
I'll share the updated bz2gitlab migration script asap. My main concern about gitlab issues is that comments are not searchable, only the description is.

gael

> ** hg to git **
>
> 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.

I agree that it won't be required that often (most "grafted from"
references are very close to each other anyway). If we have some tool
which can look-up hashes I think we are fine. (I won't prevent anyone
from trying to translate the hashes inside the history, of course *g*)

Christoph

>
> 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: christoph.hertzberg@xxxxxxx

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
-------------------------------------------------------------