Earlier I used gitifyhg to convert But if that tool worked, why bother with alternatives
On 18:59, Sun, Jun 7, 2015 Bruno Oliveira <nicodde...@gmail.com> wrote: > No problem, if everybody agrees. > > I'm playing with converting the mercurial repository to Git, having used > the HgGit plugin (http://hg-git.github.io/) and pushed the converted > repository to https://github.com/nicoddemus/pytest-issues-migration. > Seems OK to me, but does anyone with more experience want to suggest some > other approach perhaps? > > I think a good time to do the complete migration would be during the > weekend when there is not much going on repository and issue wise. How does > next Saturday (June 13th) sound to everyone? > > On Sat, Jun 6, 2015 at 7:15 AM Anatoly Bubenkov <bubenk...@gmail.com> > wrote: > >> Sounds like a good plan! >> It's easier to implement it by one person I think and that person is you! >> :) >> >> On 05:46, Sat, Jun 6, 2015 Bruno Oliveira <nicodde...@gmail.com> wrote: >> >>> Implemented the last suggestions by Florian, I think issue migration >>> looks good now. >>> >>> What would be the next steps? I suggest the following list (from the top >>> of my head): >>> >>> 1. Create github.com/pytest-dev/pytest and move issues (better do this >>> first so the migrated issues have the same id as the original ones); >>> 2. Convert pytest Hg repository to Git and upload to GitHub; >>> 3. Add to bitbucket's README a notice about the move to GitHub, and that >>> new issues/PRs should be posted there; >>> 4. Update all links in the documentation and PyPI; >>> 5. Update "how to contribute" docs; >>> 6. Upload new docs to pytest.org; >>> 7. Ask submitters to re-create PRs at the new repository; >>> 8. Send an email to all relevant mailing lists about the migration; >>> >>> After the migration process is complete, we can start to take advantage >>> of GitHub's ecosystem, for example start using Travis for CI, code coverage >>> with coveralls.io, etc. >>> >>> IMO all this must be done in a short time, because if we start the >>> migration process and stall without completing it, links, issues, PRs etc >>> might get out of sync, so it it is better to gather a few contributors and >>> choose a "Migration Sprint" day to start and finish all the steps required >>> for a full migration. >>> >>> Cheers, >>> >>> On Fri, Jun 5, 2015 at 12:33 PM Bruno Oliveira <nicodde...@gmail.com> >>> wrote: >>> >>>> On Fri, Jun 5, 2015 at 1:19 AM Florian Bruhin <m...@the-compiler.org> >>>> wrote: >>>> >>>>> > When doing the final migration, which user should we use? >>>>> >>>>> I suggest creating a new user for the migration so it's immediately >>>>> apparent that's not the real issue author. >>>> >>>> >>>>> For example, a pytest-dev/pytest-bot/pytest-issue-migration/... user >>>>> with the pytest logo as avatar. >>>>> >>>> >>>> Yes, that seems like a good solution. :) >>>> >>>> About your other suggestions, I agree with most of them and created an >>>> issue with your points here: >>>> https://github.com/nicoddemus/bitbucket_issue_migration/issues/2 >>>> >>>> There are only two which I don't think are worth the effort: >>>> >>>> - Porting PRs seems to be tricky, since we would have to port the >>>> patches as well; >>>> - Update the changesets that appear in issues/comments: since those >>>> changesets will be different when we convert from Mercurial to Git, there's >>>> no easy way to map them; >>>> >>>> If others have any more suggestions, feel free to comment here or at >>>> https://github.com/nicoddemus/bitbucket_issue_migration/issues/2. >>>> >>>> Cheers, >>>> >>>> >>>>> I think the "Bitbucket / originally reported by" footer should be at >>>>> the top (before the issue text) instead - again so it's immediately >>>>> apparent what's going on. >>>>> >>>>> Also, stuff inside <> seems to be removed? >>>>> See >>>>> https://github.com/nicoddemus/pytest-issues-migration/issues/6#issuecomment-109143858 >>>>> for example. >>>>> >>>>> Some other ideas which might or might not be worth the effort: >>>>> >>>>> - Rewrite full links to an issue (as opposed to #nnn identifiers) to >>>>> point to the correct/new location (or to use #nnn instead) >>>>> >>>>> - Rewrite links to PRs, if PRs will be migrated >>>>> >>>>> - Rewrite those "-> <<cset ...>>" comments to point at git commits >>>>> (when the repo is migrated) instead of hg changesets). >>>>> (See link above for a [broken] example) >>>>> >>>>> Florian >>>>> >>>>> -- >>>>> http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) >>>>> GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc >>>>> I love long mails! | http://email.is-not-s.ms/ >>>>> >>>> _______________________________________________ >> >> >>> pytest-dev mailing list >>> pytest-dev@python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >>
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
