Open mspraggs opened 7 years ago
Sorry for waiting until the weekend to reply, but the last week has been pretty hectic for me!
Anyway, while I'm not overly fussed about the repo being public, I do think that if we intend to finish this, it'd probably be better to keep it private. Unless someone voices that they'd rather make it public, I'll shift everything over tomorrow (Sunday).
Sorry for the late reply, just got back from loch Ness. I have no objections to you moving it over.
Finally.
After a lot of faffing about with ssh's and whatnot, there is now a BitBucket repo. with all of the code and commits and everything in. Unfortunately, some cheeky person had already stolen my username, so the account is "Fyll-nds" instead.
I assume I now just have to wait until you have accounts, then invite you over.
I'm on as DivFord.
Were you able to copy the comment threads, or should we copy important ideas over?
My username on BitBucket is (drumroll please...) mspraggs, if you'd care to invite me.
Also is it cool to wipe the history here and make the repo public?
The issues have not copied over. We can therefore either just start a few new threads for the important issues, or do some fancy stuff to copy them over.
I'd try doing the fancy stuff myself, but I'm not at home, and I don't think these computers have Git on them (and I shouldn't be playing around with this sort of thing here anyway).
I believe I've shared repo. access with you (as admins) now.
@mspraggs: Presumably yes, after the issues have been moved/created. I have no problems once that's done.
Sorry, I'm not explaining this well. At the risk of patronising, I'll explain more clearly. GitHub is a layer on top of git, and as such there are things, such as issues, that aren't an integral part of git. I propose the following strategy, if we are to migrate the issues (feel free to comment/suggest alternatives):
This would at least take the pressure off me writing a script and acquainting myself with the REST APIs in a day (my student voucher expires tomorrow), and the "legacy" issues would still be visible in the interim.
Thoughts?
P.S. Thanks Iain for taking the time to copy the repository over to GitHub.
That sounds like a solid plan. I was trying to work out how to export the issues/wiki, but a job just came through, so I won't have time. Glad to hear there's time to spare on that bit.
Sounds fine. I'd got it in my head that you were going to essentially empty-then-delete this repo. today/tomorrow, but if you're just emptying it, then all's good.
As you may have noticed, I've erased history on this remote (and all tags, which for some reason GitHub doesn't delete when history is rewritten). Now I'll make the repo public.
WRT migrating the issues, it might be simpler just to copy-paste the wiki (since it's quite small), then consolidate the relevant info from the issues into the new wiki. We can open new issues for anything that actually needs doing, but a lot of our issues are more like discussions, and might be easier to refer to in wiki form. Just a thought...
While it is occasionally fun to flick back through the old issues and laugh at the problems we were having (or the arguments we got into...), I wouldn't be too distraught if they were all just deleted. Then again, some of them (e.g. the Puzzle vs Mario one #110) are quite long and wordy, so I'd hate to be the one copying them over.
Depending on how much information we judge as the minimum that we'd like to keep, it'd potentially be easier to do fiddly REST stuff.
And you learn a new skill in the process :-P
The other thing with copy-pasting stuff is that the formatting is achieved through Markdown, so unless you click edit on every comment you'll lose any nice hyperlinks/other formatting.
I had a quick flick through a few to see which seem the most important, and it was pretty hard to tell. Pretty much everything that's still open has some unresolved factor to it (which is wh yit's still open, I suppose. It also makes me feel that we should make a dedicated topic or wiki page or something which just has a list of art assets needing doing (sorry David!), as opposed to having a separate one in each issue, essentially).
So yeah, put my vote down for fiddly REST stuff (done by someone else, mind :P).
Ugh, must I? Okay. I mean to be fair this can probably/hopefully be scripted in Python in a relatively brief manner. And I know Iain isn't Python's biggest fan, so I suppose it makes sense for me to do it. Poke me/bump this thread by this time next week if I don't appear to have done anything.
I've got nothing against Python per se (heck, I use it myself whenever I need to write a short program), I just think it's notation should stay in its own language. :P
I'd appreciate it if someone else did it (I did set up the new repo. after all... I'm going to be milking that one for the remainder of this project), but could look into it this evening if you really don't want to do it.
I will do it, because I'd like to have a peek into REST frameworks for my own interest. I'll share whatever I cook up with you guys.
Python notation? You mean whitespace over curly braces? Python doesn't claim ownership of that I don't think...
I assumed your belief in my dislike of Python came from the Python-style-for-loops (as that's the main time that Python has come up that I can recall). If not, nevermind then!
I tried doing the export, but for some reason it's claiming there's no module called 'github', even though it shows up in my module list. Any ideas?
Do you have some code David? What're you trying to do exactly?
EDIT: If you're working in Python, this almost certainly means you'll need to install some module that implements the REST interface for GitHub. I think the latest version of the REST API is v3, though I might be wrong.
It's from the page Iain linked to. BitBucket created an import/export function, and someone wrote a python script to export github issues to the BitBucket export format (here). I installed the dependency (PyGithub), and it shows up when I list modules in Python, but when I run the script it says "No module named github".
I am able to run this successfully inside a Python virtual environment. I will restart the export once I've posted this. I'll upload the result once I've finished, so Iain can import it to BitBucket. Any comments made whilst I'm running the export code may not get exported, so you're aware (I don't know how the code David linked to works).
Hi guys,
I got an email from GitHub today telling me they will start charging my account if I don't downgrade it to a free one by the 18th October. I don't really want a paid account, given this is a small project and I don't have a large number of other private projects. In any case I haven't really led on the development of this project for quite a while, so I don't think it makes much sense for me to host the remote repo anymore.
May I suggest that this remote is migrated to BitBucket, a provider of unlimited free private repositories, provided the number of collaborators is no more than five. May I recommend that Iain does this migration, since he has contributed the most lines of code. It isn't complicated. Summary workflow:
git remote set-url origin <new bitbucket url>
I will be downgrading all my repos to public ones on Monday afternoon (17th October), followed by my account. I will also clone the repo as it stands now in case you don't see this by the time I start downgrading the repos.
The act of downgrading the repos will make all issues readable to everyone browsing the repository. I propose that I force-push a commit that wipes the entire revision history from the remote on GitHub. This way the code and associated assets can't be obtained by anyone. I'll do this on Monday before I make all my closed repos open.
Alternatively, if you guys don't really care about others seeing our code then we can just make the repo public and save ourselves some hassle. We would need to put some sort of notice on copying into the repo root directory.