08-22-2014, 07:30 AM (This post was last modified: 08-22-2014, 07:38 AM by divVerent.)
Hi everyone!
We are moving our development infrastructure from a self-hosted Git service (at nl.git.xonotic.org) to a third-party hoster.
This will enable more collaboration, as well as better and faster code reviewing than our current infrastructure (thanks to a great diff view, review comments features, and more), and thus will greatly improve the development experience. I will even get to review samual/weapons piece by piece with it!
If you have commit access to part of our repository:
Please create an account at gitlab (if you already have a Google, Twitter or Github account, you may skip this step and log in through these services instead).
Click your user icon in the top right, then Settings, then SSH keys. Upload your SSH key there.
In one week (on Friday, Aug 29), I will turn off push access to the old server, and enable your user accounts to push to gitlab. The exact procedure for reconfiguring your Git clients will be posted at a later time, but it should boil down to running "./all update -p" twice in a row after the switchover.
If you don't have commit access, "./all update" will handle all necessary transitioning. No extra work for you to do. It might fail once - in which case you should just run it again.
Issues and Wiki currently stored on dev.xonotic.org will not get lost, however, will be frozen in a read-only state. All data that can be ported will be ported. Formatting and issue status will be preserved as much as possible, however, the posts will unfortunately not be associated with your user profile.
We will still keep a copy of all data for backup reasons, and because it's cheap to do. The mirror de.git.xonotic.org will stay up.
Thanks for the info, I wasn't fully aware of what was going on. And thanks for picking a FLOSS webapp, that's awesome.
Will you answer questions in this thread? I have a few.
About mirrors:
1. What git servers does that leave us with? IIRC we had trouble with the US mirror, so I suppose it has been taken down. That leaves gitlab and de.git. Is de.git read-only now?
About hosting:
2. Is there any cost for hosting on gitlab's servers? Do we know if that cost will evolve over time?
3. Did you consider running our own instance of gitlab? Any reason we didn't go with that? If in the future we were to opt for this, can the move be done conveniently?
About the tracker:
4. You say posts that are ported over from redmine won't belong to our user accounts. That's completely understandable. Can you still put whatever data that would otherwise be lost (username, timestamp?) as a prefix to the text of the messages so that we can still get a clue from this?
5. Does gitlab provide a similar wiki capability, or do we have to start over? Starting over wouldn't be very bad news if we can archive what we've had so far somewhere safe, on a static mirror or something like that.
(08-22-2014, 12:05 PM)Mr. Bougo Wrote: Thanks for the info, I wasn't fully aware of what was going on. And thanks for picking a FLOSS webapp, that's awesome.
Will you answer questions in this thread? I have a few.
About mirrors:
1. What git servers does that leave us with? IIRC we had trouble with the US mirror, so I suppose it has been taken down. That leaves gitlab and de.git. Is de.git read-only now?
That leaves gitlab and de.git.xonotic.org as mirrors. The US mirror was broken for ages and can be considered gone.
The mirrors always were read-only. Pushing always goes to the authoritative server (in the past in the Netherlands, soon at Gitlab).
Quote:About hosting:
2. Is there any cost for hosting on gitlab's servers? Do we know if that cost will evolve over time?
Gitlab provides this as a free service.
Quote:3. Did you consider running our own instance of gitlab? Any reason we didn't go with that? If in the future we were to opt for this, can the move be done conveniently?
I did consider it, however, it is about administration time cost. I'd prefer someone else to manage this to stay away from administration pain. The git repo was "okay" regarding this (but its configs would need to be rewritten for an upgrade to a newer version), but redmine... PLEASE NOT.
If we later want to migrate to our own instance, we can - even including the users - if we write our own migration script (there unfortunately is no existing one, but there is a full featured API that can do this). Running our own gitlab especially would mean we get a "sudo" like functionality that would allow for creating issues under the name of another user.
Quote:About the tracker:
4. You say posts that are ported over from redmine won't belong to our user accounts. That's completely understandable. Can you still put whatever data that would otherwise be lost (username, timestamp?) as a prefix to the text of the messages so that we can still get a clue from this?
Exactly that is the plan.
Quote:5. Does gitlab provide a similar wiki capability, or do we have to start over? Starting over wouldn't be very bad news if we can archive what we've had so far somewhere safe, on a static mirror or something like that.
There is a wiki, and I also want to import its data. The catch is that I will need to convert from Textile to Markdown, which means some formatting may get lost. Once detected, we can fix that manually then.
08-23-2014, 05:19 PM (This post was last modified: 08-23-2014, 05:20 PM by Mr. Bougo.)
Don't take my word for it, but I don't think this should affect your local clones at all, unless the ./all script does it. But git itself is pretty much remote-agnostic.
Ah, maybe it's worth noting that the static mirroring means the urls aren't exactly the same (.html suffix, ? becoming @, and others?) so links to issues require a .html added at the end to work. Perhaps url rewriting on just the issue links would be helpful there.
On a side note, update -p might ask to authorize gitlab.com, in which case one can compare the public key fingerprint here: https://about.gitlab.com/gitlab-com/
I could be be wrong, but I'm pretty sure you can't update a MySQL table with let alone HTML, you need a server-side scripting language to assist you ie. PHP, ASP..
12-11-2014, 02:11 PM (This post was last modified: 12-11-2014, 02:11 PM by Mr. Bougo.)
(12-11-2014, 10:34 AM)R19Sn Wrote: I could be be wrong, but I'm pretty sure you can't update a MySQL table with let alone HTML, you need a server-side scripting language to assist you ie. PHP, ASP..