| Hi,
> ** 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.
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.
> ** 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.
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?
David
> ** 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)
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
-------------------------------------------------------------
|