| Re: [eigen] Bitbucket is dropping its Mercurial support! |
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
| Hi all, 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 3.3 9 3.2 9 find-module-imported-target 9 fix_cuda_clang 9 CUDA_9.0 9 patch-1 9 3.1 9 3.0 9 2.0 9 If we also consider closed branches (what we probably should) I also get 9 links (using hg branches -c). A short manual look at the links shows that they are all the same 9 (remains to be checked!). That said this is something we can easily fix manually. 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. 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. 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. I see essentially three options: 2. Convert to git, stay at 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. 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). Thanks, David
|
| Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |