Re: [eigen] Bitbucket migration

[Gael Guennebaud]

Hi,

yes, I've already found this email, and sent him a message on the 6th of
September and a reminder on the 17th. But no reply.

gael

On Wed, Oct 2, 2019 at 11:00 PM Rasmus Munk Larsen 
wrote:

> It looks like the person's work email might be found here:
> https://www.ht.sfc.keio.ac.jp/~eigen/
> Gael or Christoph, would you consider contacting them directly?
>
> On Wed, Oct 2, 2019 at 1:56 PM David Tellenbach <
> david.tellenb...@tellnotes.org> wrote:
>
>> Hi all,
>>
>> It also looks like there has been no activity for 10 months on that
>> account:
>>
>> https://gitlab.com/users/eigen/activity
>>
>>
>> This doesn't seem to be enough:
>> https://about.gitlab.com/support/#dormant-namespace-requests states that
>> two years of inactivity are required. However, it's always possible to ask.
>>
>> David
>>
>>
>> On 2. Oct 2019, at 22:47, Rasmus Munk Larsen  wrote:
>>
>> It also looks like there has been no activity for 10 months on that
>> account:
>>
>> https://gitlab.com/users/eigen/activity
>>
>> On Tue, Oct 1, 2019 at 4:26 PM Patrik Huber 
>> wrote:
>>
>>> Hi Gael,
>>>
>>> >> since "eigen" is already taken (and I got no answer from the owner
>>> despite one reminder)
>>>
>>> Have you contacted GitLab support about this? They're usually quite
>>> responsive. Eigen is a project with quite some weight behind it, it may not
>>> be unlikely that they can do something.
>>>
>>> -Patrik
>>>
>>> On Wed, 18 Sep 2019 at 09:55, Wood, Tobias 
>>> wrote:
>>>
 *> *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!



 I am one of the users of the current github mirror, and yes, as I
 understand it option 3 isn’t really an option because of the re-written
 history. I see no point in it.



 I think option (1) is best. I look forward to swapping over to the
 gitlab mirror.



 Toby

>>>
>>

Re: [eigen] Bitbucket migration

[Rasmus Munk Larsen]

It looks like the person's work email might be found here:
https://www.ht.sfc.keio.ac.jp/~eigen/
Gael or Christoph, would you consider contacting them directly?

On Wed, Oct 2, 2019 at 1:56 PM David Tellenbach <
david.tellenb...@tellnotes.org> wrote:

> Hi all,
>
> It also looks like there has been no activity for 10 months on that
> account:
>
> https://gitlab.com/users/eigen/activity
>
>
> This doesn't seem to be enough:
> https://about.gitlab.com/support/#dormant-namespace-requests states that
> two years of inactivity are required. However, it's always possible to ask.
>
> David
>
>
> On 2. Oct 2019, at 22:47, Rasmus Munk Larsen  wrote:
>
> It also looks like there has been no activity for 10 months on that
> account:
>
> https://gitlab.com/users/eigen/activity
>
> On Tue, Oct 1, 2019 at 4:26 PM Patrik Huber  wrote:
>
>> Hi Gael,
>>
>> >> since "eigen" is already taken (and I got no answer from the owner
>> despite one reminder)
>>
>> Have you contacted GitLab support about this? They're usually quite
>> responsive. Eigen is a project with quite some weight behind it, it may not
>> be unlikely that they can do something.
>>
>> -Patrik
>>
>> On Wed, 18 Sep 2019 at 09:55, Wood, Tobias  wrote:
>>
>>> *> *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!
>>>
>>>
>>>
>>> I am one of the users of the current github mirror, and yes, as I
>>> understand it option 3 isn’t really an option because of the re-written
>>> history. I see no point in it.
>>>
>>>
>>>
>>> I think option (1) is best. I look forward to swapping over to the
>>> gitlab mirror.
>>>
>>>
>>>
>>> Toby
>>>
>>
>

Re: [eigen] Bitbucket migration

[David Tellenbach]

Hi all,

> It also looks like there has been no activity for 10 months on that account: 
> 
> https://gitlab.com/users/eigen/activity 
> 
This doesn't seem to be enough: 
https://about.gitlab.com/support/#dormant-namespace-requests 
 states that two 
years of inactivity are required. However, it's always possible to ask.

David


> On 2. Oct 2019, at 22:47, Rasmus Munk Larsen  wrote:
> 
> It also looks like there has been no activity for 10 months on that account: 
> 
> https://gitlab.com/users/eigen/activity 
> 
> 
> On Tue, Oct 1, 2019 at 4:26 PM Patrik Huber  > wrote:
> Hi Gael,
> 
> >> since "eigen" is already taken (and I got no answer from the owner despite 
> >> one reminder)  
> 
> Have you contacted GitLab support about this? They're usually quite 
> responsive. Eigen is a project with quite some weight behind it, it may not 
> be unlikely that they can do something.
> 
> -Patrik
> 
> On Wed, 18 Sep 2019 at 09:55, Wood, Tobias  > wrote:
> > 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!
> 
>  
> 
> I am one of the users of the current github mirror, and yes, as I understand 
> it option 3 isn’t really an option because of the re-written history. I see 
> no point in it.
> 
>  
> 
> I think option (1) is best. I look forward to swapping over to the gitlab 
> mirror.
> 
>  
> 
> Toby
> 

Re: [eigen] Bitbucket migration

[Patrik Huber]

Hi Gael,

>> since "eigen" is already taken (and I got no answer from the owner
despite one reminder)

Have you contacted GitLab support about this? They're usually quite
responsive. Eigen is a project with quite some weight behind it, it may not
be unlikely that they can do something.

-Patrik

On Wed, 18 Sep 2019 at 09:55, Wood, Tobias  wrote:

> *> *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!
>
>
>
> I am one of the users of the current github mirror, and yes, as I
> understand it option 3 isn’t really an option because of the re-written
> history. I see no point in it.
>
>
>
> I think option (1) is best. I look forward to swapping over to the gitlab
> mirror.
>
>
>
> Toby
>

Re: [eigen] Bitbucket migration

[Wood, Tobias]

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

I am one of the users of the current github mirror, and yes, as I understand it 
option 3 isn’t really an option because of the re-written history. I see no 
point in it.

I think option (1) is best. I look forward to swapping over to the gitlab 
mirror.

Toby

Re: [eigen] Bitbucket migration

[Gael Guennebaud]

On Wed, Sep 18, 2019 at 9:10 AM Christoph Hertzberg <
c...@informatik.uni-bremen.de> 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 <
> gael.guenneb...@gmail.com>
> > 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
> 

Re: [eigen] Bitbucket migration

[Christoph Hertzberg]

Very nice indeed! Thanks Gael and Joseph!

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).
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).
Also, we should probably host the "last official" state of the mercurial 
repository somewhere (as read-only).


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 
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:   christoph.hertzb...@dfki.de

 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
  

Re: [eigen] Bitbucket migration

[Rasmus Munk Larsen]

Wow, very impressive! Thanks, Gael!

On Tue, Sep 17, 2019 at 2:31 PM 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 
> 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
>>
>>
>>

Re: [eigen] Bitbucket migration

[Yuanchen Zhu]

Holy cow this looks impressive!

On Tue, Sep 17, 2019 at 2:31 PM 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 
> 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
>>
>>
>>

Re: [eigen] Bitbucket migration

[Gael Guennebaud]

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

Re: [eigen] Bitbucket migration

[Mark Sauder]

Dear Eigen,

I feel like I've given enough time for someone else to speak up about this
but haven't seen this commentary.  There is a reason that Eigen hasn't
migrated to git earlier and it is also the same reason that there are 6
year old PRs waiting in queue and not closed out or commented on... Eigen
is not well.

Eigen Curators, you have not listened to your audience, you have not
accepted good, hard, work to keep your library alive and improved; you have
not kept up with the times. Simply put, you have let opportunity pass Eigen
by for more than half a decade. Literally for the past 5 years no one
outside of a few maintainers has done anything for Eigen becuase PR's don't
get accepted and change is not embraced.

Please don't let this chance get missed. Migrate to git, start accepting
good work, embrace a fresh start.  And most importantly, don't only let 5
maintainers do all of the work.  If you cant do that, you will only see
less activity, more forks so people can get what they want, and less useage
of Eigen as a package, with more fragmentation and worse results. This has
been the case for Eigen since 2015.

This is not meant to be negative, only meant to be honest retrospective.
This is a very god chance for Eigen to see a brighter future than it has.
It's dying right now, but that can be changed.  I think this will be my
last email to the community in this forum but I will watch from afar.

Thanks for everything!

--
Respectfully,

Mark Sauder
c: 801.698.8786 


On Wed, Sep 11, 2019 at 10:04 AM Gael Guennebaud 
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
>
>
>

Re: [eigen] Bitbucket migration

[Joseph Mirabel]

I added a commit on my fork of fast-export which generate a file with
lines as

hg_rev_number hg_hash git_hash


I pushed it to https://github.com/jmirabel/eigen_tmp/blob/master/hg2git-map

Obviously, it should be put in another place.


fast-export can also add hg hashes as notes to git commits. That may be
a good place as well.


Joseph


Le 12/09/2019 à 16:41, Gael Guennebaud a écrit :
>
> Excellent! Thanks a lot!
>
> Do you have a hash translation table in some form that I could use in
> the other scripts?
>
> gael
>
> On Thu, Sep 12, 2019 at 1:46 PM Joseph Mirabel  > wrote:
>
> Hello Gael,
>
> I applied the changes you requested and force-pushed to
> github.com/jmirabel/eigen_tmp 
>
> Joseph
>
>
> Le 12/09/2019 à 11:46, Gael Guennebaud a écrit :
> >
> > So for me this is all good, I would only care about updating
> > references to bugs/PR by applying the following substitutions:
> >
> > "([Bb]ug) (\d+)" -> "\2 #\1"
> > "bugs (\d+) and (\d+)" -> "bugs #\1 and #\2"
> > "http://eigen.tuxfamily.org/bz/show_bug.cgi\?id=(\d+)
> " -> "#\1"
> > "[Pp]ull [Rr]equest #(\d+)" -> "pull request PR-\1"
> > "PR #(\d+)" -> "PR-\1"
>
>

Re: [eigen] Bitbucket migration

[Christoph Hertzberg]

Ah sorry, I should have tried that locally myself :)

Christoph

On 12/09/2019 17.18, Gael Guennebaud wrote:

On Thu, Sep 12, 2019 at 4:50 PM Christoph Hertzberg <
c...@informatik.uni-bremen.de> wrote:


Small question, maybe I'm just missing it:
Did you actually translate the 3.x, 2.0 branches as well or just the
default/master branch?



I just ran the script, and all branches and tags are there, so I guess he
only pushed the master branch.

I'd actually be fine with filtering out all other named branches ...




Of course we should keep only 2.0 , 3.0, 3.1, 3.2, 3.3, and master and
ignore the others.



Also, is it possible to apply the tags (from ./.hgtags)?



same, you have to "git push --tags"

See: https://gitlab.com/ggael/eigen-tmp (I pushed all branches :( )

gael




But I agree, great work!
Christoph

On 12/09/2019 16.41, Gael Guennebaud wrote:

Excellent! Thanks a lot!

Do you have a hash translation table in some form that I could use in the
other scripts?

gael

On Thu, Sep 12, 2019 at 1:46 PM Joseph Mirabel 
wrote:


Hello Gael,

I applied the changes you requested and force-pushed to
github.com/jmirabel/eigen_tmp

Joseph


Le 12/09/2019 à 11:46, Gael Guennebaud a écrit :


So for me this is all good, I would only care about updating
references to bugs/PR by applying the following substitutions:

"([Bb]ug) (\d+)" -> "\2 #\1"
"bugs (\d+) and (\d+)" -> "bugs #\1 and #\2"
"http://eigen.tuxfamily.org/bz/show_bug.cgi\?id=(\d+)



" -> "#\1"

"[Pp]ull [Rr]equest #(\d+)" -> "pull request PR-\1"
"PR #(\d+)" -> "PR-\1"








--
   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.hertzb...@dfki.de

   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
-








--
 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.hertzb...@dfki.de

 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
  -

Re: [eigen] Bitbucket migration

[Gael Guennebaud]

On Thu, Sep 12, 2019 at 4:50 PM Christoph Hertzberg <
c...@informatik.uni-bremen.de> wrote:

> Small question, maybe I'm just missing it:
> Did you actually translate the 3.x, 2.0 branches as well or just the
> default/master branch?
>

I just ran the script, and all branches and tags are there, so I guess he
only pushed the master branch.

I'd actually be fine with filtering out all other named branches ...
>

Of course we should keep only 2.0 , 3.0, 3.1, 3.2, 3.3, and master and
ignore the others.


> Also, is it possible to apply the tags (from ./.hgtags)?
>

same, you have to "git push --tags"

See: https://gitlab.com/ggael/eigen-tmp (I pushed all branches :( )

gael


>
> But I agree, great work!
> Christoph
>
> On 12/09/2019 16.41, Gael Guennebaud wrote:
> > Excellent! Thanks a lot!
> >
> > Do you have a hash translation table in some form that I could use in the
> > other scripts?
> >
> > gael
> >
> > On Thu, Sep 12, 2019 at 1:46 PM Joseph Mirabel 
> > wrote:
> >
> >> Hello Gael,
> >>
> >> I applied the changes you requested and force-pushed to
> >> github.com/jmirabel/eigen_tmp
> >>
> >> Joseph
> >>
> >>
> >> Le 12/09/2019 à 11:46, Gael Guennebaud a écrit :
> >>>
> >>> So for me this is all good, I would only care about updating
> >>> references to bugs/PR by applying the following substitutions:
> >>>
> >>> "([Bb]ug) (\d+)" -> "\2 #\1"
> >>> "bugs (\d+) and (\d+)" -> "bugs #\1 and #\2"
> >>> "http://eigen.tuxfamily.org/bz/show_bug.cgi\?id=(\d+)
> 
> >> " -> "#\1"
> >>> "[Pp]ull [Rr]equest #(\d+)" -> "pull request PR-\1"
> >>> "PR #(\d+)" -> "PR-\1"
> >>
> >>
> >>
> >
>
> --
>   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.hertzb...@dfki.de
>
>   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
>-
>
>
>
>

Re: [eigen] Bitbucket migration

[Christoph Hertzberg]

Small question, maybe I'm just missing it:
Did you actually translate the 3.x, 2.0 branches as well or just the 
default/master branch?


I'd actually be fine with filtering out all other named branches ...

Also, is it possible to apply the tags (from ./.hgtags)?

But I agree, great work!
Christoph

On 12/09/2019 16.41, Gael Guennebaud wrote:

Excellent! Thanks a lot!

Do you have a hash translation table in some form that I could use in the
other scripts?

gael

On Thu, Sep 12, 2019 at 1:46 PM Joseph Mirabel 
wrote:


Hello Gael,

I applied the changes you requested and force-pushed to
github.com/jmirabel/eigen_tmp

Joseph


Le 12/09/2019 à 11:46, Gael Guennebaud a écrit :


So for me this is all good, I would only care about updating
references to bugs/PR by applying the following substitutions:

"([Bb]ug) (\d+)" -> "\2 #\1"
"bugs (\d+) and (\d+)" -> "bugs #\1 and #\2"
"http://eigen.tuxfamily.org/bz/show_bug.cgi\?id=(\d+)

" -> "#\1"

"[Pp]ull [Rr]equest #(\d+)" -> "pull request PR-\1"
"PR #(\d+)" -> "PR-\1"








--
 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.hertzb...@dfki.de

 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
  -

Re: [eigen] Bitbucket migration

[Gael Guennebaud]

Excellent! Thanks a lot!

Do you have a hash translation table in some form that I could use in the
other scripts?

gael

On Thu, Sep 12, 2019 at 1:46 PM Joseph Mirabel 
wrote:

> Hello Gael,
>
> I applied the changes you requested and force-pushed to
> github.com/jmirabel/eigen_tmp
>
> Joseph
>
>
> Le 12/09/2019 à 11:46, Gael Guennebaud a écrit :
> >
> > So for me this is all good, I would only care about updating
> > references to bugs/PR by applying the following substitutions:
> >
> > "([Bb]ug) (\d+)" -> "\2 #\1"
> > "bugs (\d+) and (\d+)" -> "bugs #\1 and #\2"
> > "http://eigen.tuxfamily.org/bz/show_bug.cgi\?id=(\d+)
> " -> "#\1"
> > "[Pp]ull [Rr]equest #(\d+)" -> "pull request PR-\1"
> > "PR #(\d+)" -> "PR-\1"
>
>
>

Re: [eigen] Bitbucket migration

[Gael Guennebaud]

On Thu, Sep 12, 2019 at 9:53 AM Joseph Mirabel 
wrote:

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

$ hg log -v  | grep "backporting"  does not give me that many:

backporting 1784: fixed bug #62

-> For this one "hg log -r 1784" tells me that the true hash is
0430786c2a6f (but we don't care if we lost one link!)

The followings are very old subversion references, we don't care at all:

backporting 964177 (gcc 3.3 fix)
backporting r964165 (gcc 3.3 fixes)
backporting rev 951682 (compilation fix in aligned allocator)
backporting rev 918446: fix MSVC internal compilation error
backporting rev925153 (bugfix in MapBase::coeffRef(int) )
backporting commit 918468 (fix MSVC internal error)


> - I do not catch ranges of revision number like "[0-9]+-[0-9]+". It
> wouldn't be hard to achieve.
>
-> I could not find any meaningful one.

I only found two meaningful "([0-9]+:)([0-9]+)" occurrences like:
6089:76b6c62565a6. In this case, if \2 is a valid hash, then \1 (e.g.,
"6089:") should be dropped to enable auto-link creation, see:
https://github.com/jmirabel/eigen_tmp/commit/4325f05a4b60

But that's really no big deal as the true hash has been properly updated,
and there are only 2 occurrences!

> - 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).
>
I guess this issue is related to changeset 59a7e404a93c, which is an empty
commit closing a branch. If your script ignores it without additional
issue, then that's fine.

So for me this is all good, I would only care about updating references to
bugs/PR by applying the following substitutions:

"([Bb]ug) (\d+)" -> "\2 #\1"
"bugs (\d+) and (\d+)" -> "bugs #\1 and #\2"
"http://eigen.tuxfamily.org/bz/show_bug.cgi\?id=(\d+)" -> "#\1"
"[Pp]ull [Rr]equest #(\d+)" -> "pull request PR-\1"
"PR #(\d+)" -> "PR-\1"


gael


>
> Joseph
>
>
> Le 12/09/2019 à 00:37, Gael Guennebaud a écrit :
>
>
>
> On Wed, Sep 11, 2019 at 7:38 PM Joseph Mirabel 
> wrote:
>
>> Dear Eigen developers,
>>
>> - I can convert all reference like to revisions or mercurial hashes that
>> follows the regex in [2].
>>
>
> I'll look at it more carefully later, but... wow!! this looks very
> promising: https://github.com/jmirabel/eigen_tmp/commit/6e53e31dc2d79da
>
> For comparison, the same commit in our official git-mirror:
> https://github.com/eigenteam/eigen-git-mirror/commit/6ba9310bc2c168
>
> 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

Re: [eigen] Bitbucket migration

[Gael Guennebaud]

On Thu, Sep 12, 2019 at 12:59 AM David Tellenbach <
david.tellenb...@tellnotes.org> 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 
> wrote:
>
>
>
> On Wed, Sep 11, 2019 at 6:50 PM Christoph Hertzberg <
> c...@informatik.uni-bremen.de> 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"

Re: [eigen] Bitbucket migration

[Joseph Mirabel]

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 :
>
>
> On Wed, Sep 11, 2019 at 7:38 PM Joseph Mirabel  > wrote:
>
> Dear Eigen developers,
>
> - I can convert all reference like to revisions or mercurial
> hashes that
> follows the regex in [2].
>
>
> I'll look at it more carefully later, but... wow!! this looks very
> promising: https://github.com/jmirabel/eigen_tmp/commit/6e53e31dc2d79da
>  
> For comparison, the same commit in our official
> git-mirror: 
> https://github.com/eigenteam/eigen-git-mirror/commit/6ba9310bc2c168
>
> 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
> >
> >
>
>
>

Re: [eigen] Bitbucket migration

[Christoph Hertzberg]

On 12/09/2019 01.27, Gael Guennebaud wrote:

On Wed, Sep 11, 2019 at 6:50 PM Christoph Hertzberg <
c...@informatik.uni-bremen.de> wrote:

[...]
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.


Oh, I now found this link in the other thread as well. I guess one 
problem here is that we would have both PRs and Bugs starting with #1 
Sure, it is possible to remap one of these, but that might be confusing 
as well.



Christoph



--
 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.hertzb...@dfki.de

 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
  -

Re: [eigen] Bitbucket migration

[David Tellenbach]

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   

> On 11. Sep 2019, at 23:27, Gael Guennebaud  wrote:
> 
> 
> 
> On Wed, Sep 11, 2019 at 6:50 PM Christoph Hertzberg 
> mailto:c...@informatik.uni-bremen.de>> 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 

Re: [eigen] Bitbucket migration

[Gael Guennebaud]

On Wed, Sep 11, 2019 at 6:50 PM Christoph Hertzberg <
c...@informatik.uni-bremen.de> 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.hertzb...@dfki.de
>
>   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
>-
>
>
>
>

Re: [eigen] Bitbucket migration

[Joseph Mirabel]

Dear Eigen developers,


First of all, I am not an expert with mercurial and I am fairly good
with git. I am in favor of switching to git.


I played a bit with fast-export[1]. The changes and same basic usage are
on my fork [3].

To see the result, either follow the steps in the README of my fork [3]
of fast-export or visit the temporary repository[4].


So far, here is what I did (or did not):

- I have an error related to unamed head in mercurial,

- I can convert all reference like to revisions or mercurial hashes that
follows the regex in [2].

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

Re: [eigen] Bitbucket migration

[Christoph Hertzberg]

On 11/09/2019 18.03, Gael Guennebaud 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!


Wow, that's great!!



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




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.


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.


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)



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


I guess searching for hex-numbers of a minimal length should be 
sufficient (with a plausibility check that they are a unique hg-hash). 
Of course any "https://bitbucket.org/eigen/eigen/commits/; or equivalent 
needs to be translated as well (not completely trivial, but not too 
difficult, either).





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.hertzb...@dfki.de

 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
  -