Hello!
Let me chip in here.
A good git import tool would put the mercurial hashes into the commit
messages, so there is at least any chance of finding them.
Our company uses a self hosted GitLab instance with these premium and we
had a blast. We still have a seperate issue management from gitlab, and
it just integrates with gitlab reasonably well.
Regarding gitlab CI: we don't use gitlab runner much. Gitlab EE provides
integration with Jenkins buildnodes and I'm sure other CI like travis
work as well.
So we have a mix, some nighly builds or on push builds int he gilab
runner, some CI in the runner, some CI in Jenkins, some nightly jobs in
Jenkins, mixed pipelines, some on VMs, some running natively, and it all
works well. So this shouldn't be a concern with gitlab. Also gitlab can
automatically serve mirrors on github or elsewhere if they are wanted
(and nightly CI can then run from there)
Moving to git would also allow us to subtree in Eigen into our codebase,
and to subtree pull and split, instead of copying around without any
history on each release...
Just my 2 cents,
Martin
Am 24.08.19 um 16:05 schrieb Christoph Hertzberg:
Hi!
On 24/08/2019 12.30, David Tellenbach wrote:
just some thoughts about some points you've made:
b) Fixing internal links inside commit messages ("grafted from ...",
"fixes error introduced in commit ...")
Maybe I've forgot something crucial but doing something like
for branch in $(hg branches | awk '{print $1}'); do
hg update -C $branch > /dev/null
echo "$branch $(hg log -v | egrep "bitbucket.org" | wc -l)"
done
gives me
Branch Links
------ ------
default 9
[...]
The point you missed is that especially the "grafted from" links do
not include the full URL, just the hg-hash (which is different from
git-hashes). And just greping for "grafted from" gives me 425 results
(in total -- if you want the log of individual branches, you need to
use the `-b` option).
For a more precise count, you should grep for hexadecimal numbers
longer than a few digits inside the commit messages.
I somewhat doubt that any existing hg->git converters automatically
translates these hashes, but I'd be very happy if someone finds out
otherwise. Changing these manually is definitely not an option.
Also, if we stayed with mercurial, but used a different provider, we
can't modify the history, because that would influence all the hashes
(but then only the 9 direct links to "bitbucket.org/..." you found
would be broken, which is acceptable, IMO)
Of course we can just ignore these links (though I think broken
links/hashes are even worse than non-existing ones ...)
Another point are links inside the codebase that point to bitbucket.
Following the same logic as above I use
hg grep "bitbucket.org"
and get 11 links (all seem to be the same). Again something fixable
manually.
Agreed, this part is easy to fix manually.
c) Fixing external links to the repository. Most notably, any links
from our bugtracker will eventually fail (even if we stayed with
bitbucket, the hashes won't match). I doubt that we could set up any
automatic forwarding for that.
This might be by far the most complicated point since a lot (the
majority?) of all issues contain links to commits. If desired I can
find a concrete number but I doubt that it will be very...motivating.
I also doubt that Bitbucket will provide any functionality to
redirect links to other Git providers but I could image that there
could be some workaround if we decide to migrate to Bitbucket Git.
Something we should keep in mind before choosing a new provider.
If you (or anyone else) are/is really interested, I can try to make a
MySQL dump of the underlying database (I'd need to strip the user
data). If we have some automatic translation between the hashes, this
could even allow us to automatically convert all links.
Migrating to bitbucket-git will still break all existing links, since
the hashes don't match. And as bitbucket is not even planning to
provide an automated repository conversion, I would not count on any
kind of forwarding mechanism.
Any third-party which relies on our main repository will need to
change as well (not directly "our" problem, but we need to give a
reasonable amount of time for everyone to migrate to whatever will
be our future official repository).
It's currently unclear for me what exactly will happen with the hg
repo but I guess it will be archived or something similar. In this
case we can link to the new repo on the README page. I don't have any
further ideas regarding this but also think we should migrate
somewhat fast.
Yes, I think this is unclear for everyone at the moment. The
announcement from bitbucket sounds a lot like they will literally
delete all hg-repositories in June next year :(
If it was at least frozen/archived as it is, we would have almost no
problems with point c).
For manual redirection, we can of course open a new git-project which
just contains a README.md saying that bitbucket dropped hg-support,
and point to where Eigen migrated to.
I see essentially three options:
1. Migrate to another mercurial provider
2. Convert to git, stay at bitbucket
3. Convert to git, migrate to another provider
1. We could migrate to Tuxfamily and keep mercurial. As you said this
would imply we have to handle pull requests separately which is
possible. As you surly know LLVM does exactly that by using
Phabricator. However this would fix some of the issues above but
links to bitbucket would remain a problem. Another downside of
mercurial is that only very few projects are using it and
contributing would be much easier in the case of git.
I really don't see much difference in usability between hg and git --
both have their advantages and little quirks, IMO. And I don't think
that hg was ever the main-hurdle for people contributing to Eigen ...
If Phabricator allows to import our existing PRs that would of course
be a nice option. But I'm really pessimistic about that at the moment,
since this also requires to match all users which made the PR or took
part in the discussion to the new host (maybe that would be the only
argument for staying with bitbucket).
2. The only reason I see for this is the one I mentioned above: If
there is (or will be) any support to redirect bitbucket links it will
most likely only work if we stay at bitbucket. Compared with other
code hosting services I find bitbucket (not mercurial) to be really
complicated and not intuitive.
It might be an option, if they allowed to automatically migrate
pull-requests. But at the moment, they don't even seem to plan
automatic migration of repositories.
3. In an ideal world this would be my absolute preference (not very
surprising). Regarding the choice of a service I want to make the
personal point that I would rather migrate to Gitlab than to Github
because it is as least as good as Github and I think that diversity
of tools and providers is crucial for open source. In the long run we
could even think about migrating issues to Gitlab and installing test
runners (this is another story).
In my ideal world, somebody volunteers to do the work necessary for
migration :) -- including the issues I pointed out (doesn't have to be
the same person doing everything, of course). Even some
proof-of-concept demos what can be automated would be nice!
I don't have any real preferences between mercurial/git or
github/gitlab/bitbucket.
I totally agree that having automated test runners on pull-requests
will be a big plus (for which I'm even willing to sacrifice some of my
original points, especially since we may need to anyway).
Cheers,
Christoph
Thanks,
David
On 21. Aug 2019, at 14:53, Christoph Hertzberg
<[email protected]> wrote:
Hello Eigen users and contributers!
As some may have noticed, bitbucket/atlassian is "sunsetting" its
mercurial support:
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
If they stick to their timeline, we will have to migrate until June
1st, 2020. That means we still have time, but if we do nothing,
things will break ...
Converting the repository itself to git should not be a bigger issue
-- and if we do this we could as well migrate to a more mainstream
provider (i.e., github).
I think the main problems for migration are:
a) Migrating open pull-requests (for historical reasons, the
closed/merged ones should probably be archived as well)
b) Fixing internal links inside commit messages ("grafted from ...",
"fixes error introduced in commit ...")
c) Fixing external links to the repository. Most notably, any links
from our bugtracker will eventually fail (even if we stayed with
bitbucket, the hashes won't match). I doubt that we could set up any
automatic forwarding for that.
d) Any third-party which relies on our main repository will need to
change as well (not directly "our" problem, but we need to give a
reasonable amount of time for everyone to migrate to whatever will
be our future official repository).
Smaller issues (relatively easy to fix or not as important):
e) Change links from our wiki (to downloads)
f) Change URLs for automated doxygen generation and for unit-tests
g) Automatic links from the repository to our bugtracker (currently
"Bug X" automatically links to
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=X)
h) Change hashes in bench/perf_monitoring/changesets.txt
I probably missed a few things ...
I see essentially three options:
1. Migrate to another mercurial provider
2. Convert to git, stay at bitbucket
3. Convert to git, migrate to another provider
Honestly, I see no good reason for option 2. And the only real
reason I see for option 1 would be that it safes a lot of hassle
with b) and h) -- also perhaps it would simplify c) (e.g., we could
easily crawl through our bugzilla-database and just replace some URLs).
Any opinions on this? Preferences for how to proceed, or other
alternatives?
Does anyone have experience with migrating from hg to git? Or
migrating between providers? Especially, also dealing with the
issues listed above.
Does anyone see issues I forgot?
Cheers,
Christoph
