The SVN looks down for at least 2 days.
I guess this is rather a dyndns Problem like the last two times. They bough homeunix org last year or so it seems. I wrote and Email to the maintainer.
If this keeps happening, we really need to consider moving the repository to a more reliable place. Or even switch to some DVCS, although I'd really miss the intuitiveness of being able to report bugs against a global increasing integer revision number.
that server has a dynamic ip?
If it's a static address, why not just add "svn.simutrans.com"?
If anyone supplies me a "svn dump" of the repository I can serve it from my cloud computer, or we can host it in any of our servers, Isaac exposed in the past he has enough available machines.
Quote from: Markohs on March 07, 2014, 08:33:23 AM
If anyone supplies me a "svn dump" of the repository I can serve it from my cloud computer, or we can host it in any of our servers, Isaac exposed in the past he has enough available machines.
My impression from last time isn't the ability to move the repository someplace else, but the will to move it someplace else. (pak64, and I think also some other pak sets, are hosted at out sourceforge project. There is probably only one svn repo per project though, and I don't know if importing one svn repo into another will work without making a mess.)
Using svn dunp/import works, and keeps all the repo properties. We use it at work for moving repos across servers
Quote from: Markohs on March 07, 2014, 06:13:52 PM
Using svn dump/import works, and keeps all the repo properties. We use it at work for moving repos across servers
Moving repos is one thing. Merging one repo into another is something different. For one thing, at least one of them will have to give up on it's original revision numbers.
Well, I wasn't talking about merge, as you pointed sequential revision numbers are better independent across projects. I was just pointing that uf the dns or server is not reliable any longer, we should host it somewhere else. A dedicated svn for the source code is ok imho.
Quote from: Markohs on March 07, 2014, 06:38:28 PM
Well, I wasn't talking about merge
No, but I was, since we already have an existing, stable, official svn repo.
The server changes IP daily, thanks to Deutsche Telekom. And not able to access it means also not able to dump it ...
And when we have access, there is no need to dump it...
I've split the topic because it went off-topic and the SVN is still down. And homeunix.org all together is down.
If all else fails, there is still the github mirror, but I guess we can wait one more week.
This is kind of the opposite of another open source project I know about. There the repo is still up, because it's on sourceforge, but everything else (including forum) is now completely gone. (First the DNS stopped working, but using the IP still worked for a while.)
I've tried to play with svn and can't get my head around it. But if someone wants root to get it working on the server, just let me know.
My own private SVN server, or rather SVN plugin in Apache, has been up so long I don't remember how I got it running. As far as I can remember, it was well documented. I have never tried a pure SVN server, which likely requires doing more in terms of start-up scripts and a different authentication scheme.
The best person to help move the SVN repo is likely the current maintainer. If that person doesn't get in touch, git is all we got anyway. One can run an SVN client agains GitHub, so most users shouldn't need to adapt. I don't know how committing works in that case, as I have never been able to try.
If at the end you decide to set-up svn in Iaac's servers, I can do the work if you want it.
If this does not resolve soon, we may indeed need to swap to github (and I deleted my account there just two months ago do to my frustration with the github client on windows ... )
I'd personally stick to svn.
The sequential revision numbers, patching is way easier, and the windows client is way better.
Github adds lots un unneeded complexity, imho.
But ofc, this is just my personal oppinion.
A sequential revision number could be done to git as well using hooks, i.e. submit scripts. Although those cannot run on free github, I think.
Why changing a system that has been working good enough for us. I'd just install the svn in Isaac's servers and forget about it. Changing to github is ofc, possible, but it's really worth it?
I tried working with it, and I find it complex, too complex, and no useful new feature in exchage.
I too prefer to stick with Subversion, but unless we can somehow convert a Git mirror back to Subversion, we need to get in touch with the maintainer. Since Git does thing very differently from Subversion, quite the opposite by design, this might be a lossy process.
I dare suggest a backup policy too. That would also help in cases like this one.
Let me do some tests, maybe this works:
http://chani.wordpress.com/2012/01/25/the-easy-way-to-import-from-git-into-svn/ (http://chani.wordpress.com/2012/01/25/the-easy-way-to-import-from-git-into-svn/)
I'll see if I can get a svn repo from the git one
Managed to get the export to svn working, but it's missing details, like the original author, the date, and the original revision number, that's lost. I'll investigate further to check if some of those details can be preserved.
The guide I followed:
http://sandrotosi.blogspot.com.es/2010/02/migrate-git-repo-to-svn-one.html (http://sandrotosi.blogspot.com.es/2010/02/migrate-git-repo-to-svn-one.html)
On the page you link I find:
Quote@Chris you can add the --add-author-from option to git svn dcommit to have a From: header added to the svn
revisions specifying the original author.
EDIT: Could with this technique the code go into the SF svn ... that would certainly not go down quitely. Although it had it hickups in the past too (around 2007).
I'd personally install the svn server in one of isaac's servers, and use SF one to mirror it. I can add a web frontend to the server so you can add and remove svn users easily.
But well, I don't know how easy is to add users and permissions to the SF svn server, and how much control they give to us.
After extra research, you can preserve the commit author property, and *maybe* the commit date, doing some script magic.
What's *almost* impossible to preserve is the commit version of each one, specially since branches/* were not mirrored in github, and that part of information is lost.
What whould really be ideal is tron generating a "svn export" of the repository.
Given that, and following isidoro's comment, we need to have a online backup of the whole repository one way or another, in the future, using svn or git or whatever, but we need it.
If the goal is the import to Sourgeforge, the revision numbers can't be preserver anyway. Another possible problem is that without a proper export and import, it is likely that one can't just switch existing working copies to the new repo.
I have a local git-svn clone of the complete svn repository including branch/. If that is of any help
Can you upload me that repo to make some tests Dwachs please?
@dwach
You mean with "git over svn"?
Note: One minor temporary wrinkle: I'm about to announce in Web Admin group that I've gotten a new server to transition to. It'll be faster -- and cost the same. Switching because they've added on a small "old server" fee because we've been on this one for so long. lol.
It should be a painless transition for sites -- but does mean that :if: SVN is set up on the server, we'll of course want to do it on the new one.
I should have the server released to me tonight -- but transferring stuff means it may be 2-3 days (or maybe upwards of 5 probably at worst) before we'd want to do this (to make sure DNS propagates and such).
So just a minor heads up :)
Now, back to your regularly schedule debate by you guys :)
I'm getting a bit worried about the maintainer. Does anyone know any details about the person so as to try alternative contact methods that are more likely to give some kind of response from someone?
Nope, we should start thinking what to do. Prissi and dwachs might know more
Last time I seem to remember Tron didn't realise there was a problem for a while?
I send an email, not sure what else to do. But I did it from my english address, maybe it got stuck in his filter. I resent it from more old german account today.
I'm not pushing to put on the server, just letting y'all know that it's now set up. Haven't copied things over yet, but they're clustered together so I can put new things on the new server already. :)
Quote from: kierongreen on March 14, 2014, 07:48:24 PM
Last time I seem to remember Tron didn't realise there was a problem for a while?
While not seeing that one's own DNS doesn't work is understandable, not checking e-mail at least once a week is getting rare, especially for someone running a server. He could be climbing Mount Everest, skiing to the South Pole or hiking through the Amazon rainforest, but there are worse reasons for being incommunicado that seem more likely.
Quote from: prissi on March 14, 2014, 09:34:33 PM
I send an email, not sure what else to do. But I did it from my english address, maybe it got stuck in his filter. I resent it from more old german account today.
The problem with e-mail is that it's very private. If one stops checking e-mail, then that's it. No one will really know. If you don't answer the phone, the one calling will still get some kind of feedback, whether the phone is ringing but simply not aswered, whether the phone is turned off or out of reception range, whether the subscription is cancelled, or maybe someone else answers who knows what's going on. With snail mail, either the letter is returned by the postal service, or someone else will answer it, or the recipient is actively ignoring you. This is a more personal type of contact, which in the worst case scenario can be unpleasant and awkward.
(I have a tendency to think about worst case scenarios, whether I find them likely or not.)
If moving to a different svn server, it would be good to also restore the github mirror. Otherwise everything github-based would have a hard time.
I'm not sure how/if Git-mirrors will handle a switch to a new Subversion repo (as opposed to just relocating the one we used to have). I guess it depends on whether the main mirror can keep "pulling" into the same branch.
You can have something like SVN checking out and pushing this to github. That works with any revision system and very little magic of scripting.
It seems Christoph does not get my emails. I have to assume he is on holiday.
Quote from: prissi on March 16, 2014, 09:17:57 PM
I have to assume he is on holiday.
We can only hope, but for how long?
Otherwise we can check in the git archieve into sourceforge (for isntance) ... It will mess up revision numbers, but that is proabably only a minor issue, since nobdoy will built old versions for networkgaming.
Anyone remembers is tron's server was like this:
svn://tron.homelinux.blablabla/simutrans/simutrans/{trunk,branches,tags}
*or*
svn://tron.homelinux.blablabla/simutrans/{trunk,branches,tags}
Had 2 levels of "simutrans or just one?
EDIT: Nothing, it was option 1
Why would that matter? A new repo would be a completely new URL anyway.
Was a problem I had importing the git svn copy Dwachs sent me.
I've rebuilt the svn repo, but it's a bit of a mess, author is just appended to the commit comment, the timestamps are gone too. It's taking hours to complete. Allowing commit details to be changed (this can be done), someone could make a script to update all commits with the correct value, after.
I think it's the best think we can get without a "svn export" of the original repo.
If we are moving to github, there are changes to be made to github too, because the current code relies on svn versions to work.
Quote from: Markohs on March 17, 2014, 05:18:14 PM
I've rebuilt the svn repo, but it's a bit of a mess, author is just appended to the commit comment, the timestamps are gone too.
That won't do.
Quote from: Markohs on March 17, 2014, 05:18:14 PM
If we are moving to github, there are changes to be made to github too, because the current code relies on svn versions to work.
That particular code becomes nearly pointless with Git anyway.
So, what's what we are doing to do then? Just use github and that's it? Who has the permissions on https://github.com/aburch/simutrans (https://github.com/aburch/simutrans) ? Are we using this one as master or we use a new one? Who's modifying the code to not rely on the revision.h serial number?
The first question is how long we should keep hoping that the maintainer is on vacation and when to start assuming that something worse has happened.
And Dwachs' Git copy that contains everything seems like the best starting point if we decide to abandon the previous SVN repo.
Yep, that makes sense.
If anyone is interested (even it's not very useful, since the repo lacks too much details), and for reference, the sequence to import Dwachs's repo copy into a fresh SVN repo is:
(Dwachs git copy is in "~/T2", and you are in another directory. )
(setup new svn repo so it has write access to anon, temporally, till you finish dumping)
(git will use around 1.5 Gb of memory while doing this, have it in mind, process will take around 5 hours)
svn mkdir --parents svn://NEWSERVER/simutrans/simutrans/{trunk,branches,tags}
git svn clone svn://NEWSERVER/simutrans
cd simutrans/
git remote add origin -f ~/T2/
git fetch origin master
git checkout -b old_master origin/master
git rebase --onto master --root
git svn dcommit -v --add-author-from --use-log-author
not sure, how to proceed. I sent another email. The owner of the repository seems to alive ;) No email answer still.
I would prefer to wait for him. Setting up another server will break many things ...
Just for the record, this is the result of the import, not really good:
(https://dl.dropboxusercontent.com/u/30024783/Untitled93.png)
Quote from: Dwachs on March 17, 2014, 07:49:19 PM
not sure, how to proceed. I sent another email. The owner of the repository seems to alive ;) No email answer still.
I would prefer to wait for him. Setting up another server will break many things ...
Well that's good news!
Setting up another server won't break things. Setting up another repo will. Moving the repo seems like a good idea. Isaac's server seems more stable, and isn't on dial-up with dynamic IP. I think also it's very important that two persons have the key, if not to the whole server, so at least to the file storage areas.
Setting up some automated back-up might also be a good idea. If the dump file isn't too large, I could download it from time to time if it is made available somehow.
I'll set up a svnsync backup server as soon as we recover our main svn server, just to be sure in the future.
Okay, before seting this up, I'll point to what I think should be the installation, so we can agree on the structure, before doing anything, now that the data is safe and tron admin is alive and answering.
I'd just install a main subversion server in:
svn://svn.simutrans.com/simutrans
Other projects in simutrans could get also their own svn repo, that's no problem.
I'd send the root passwords to prissi and dwachs, so there is more than one person capable of fixing things up if we fall into disaster again.
I'd use "svnserve" for this, the server shipped with subversion. I'd copy the pre-commit hooks tron has, who'd need to send them to me, or tron can be allowed to log into the server and setup the server himself.
As for backup, I'd just propose any member that has a server on the internet that wants to set up a mirror, setup read-only mirrors in their own machines, and post the info in some descriptive page. Having two RW mirrors (both in isaac's machines, or not) it's more complicated, and can give lots of problems in the future if they lose sync.
It's also very important we have mirrors outside isaac's servers, because you never know what can happen to his ISP, and we have to have a plan for those situations, even if they are extremely unlikely to happen.
About github, I'd designate one master git-svn repo, prissi's or dwachs one, that's able to push patches into the "official" svn repo, given previous approval of them. git pushes should go to them, they'd the be official git repo. This way we can get useful modifications from github pushed into subversion, from github users.
I'd keep the revision numbers for now, but someone should study where are revision numbers used atm and design a new system to stop using them.
What do you think?
As soon as we get to some agreement, we can start the tests.
Github: we could ask aburch to move the aburch/simutrans repository to the simutrans organization at github:
https://github.com/simutrans
which would be the natural choice of 'master' git server. Then commits to the svn repository can be pushed to the github mirror in a post-commit hook.
In order to incorporate contribution from others in github, the development needs to take place in github as well. Git-svn is constantly rebasing against the svn repo, which does not work well with github, I think.
Imho we should stick to using svn as the main development repository. We are used to this system. It provides meaningful revision numbers for nightly compilation and bug reporting.
Locally one still can use git-svn to develop. (I use smartgit http://www.syntevo.com/smartgithg/, which runs on Win/Linux/Mac).
I'm okay with developing only in svn, but, in fact it's my prefered option for the develompent environment. But isn't possible to have a git-svn repo, someone keeps up to date with svn, as https://github.com/aburch/simutrans (https://github.com/aburch/simutrans) does now, and make it *also* able to accept pull requests from other people, and *also* capable to push those changes *into* svn?
That whould widen our ways of contributing code, and can maybe get valuable new coders.
But ofc, we'd keep out current list of developers, that commit straight to subversion, as we do now.
It whoudn't be a active development git, just a git where some of our developers whould volunteer to review pull requests, and accept them if applicable, making them end accepted in svn automatically with a git svn dcommit? (they can appear in svn as done by the user "git", with the original commiter in the comments, like in the SS I posted.
(https://dl.dropboxusercontent.com/u/30024783/Untitled93.png)
No idea, I think it's possible, even I don't really know git much.
The github repo being named https://github.com/simutrans (https://github.com/simutrans) makes a lot of sense to me.
I think it's somewhat icky doing the integration from git to svn on github. What little I know of Git is that rebasing should be done before pushing. Messing with the history in a public repo will just cause chaos if someone manages to pull before the rebasing is done.
So, shall I install the master repo then? Dwachs, can you ask tron to send us his hooks?
Specially the pre-revprop-change, and pre-commit one.
Or, if you prefer, I can setup svn.simutrans.com as a read-only mirror of tron's one.
About the git issue... As you wish, we can allways give it a try, having backups and we'll have we can allways sort it up is we get a mess anytime.
I think that if the person administering the git, does periodic svn fetches (we can do this in a post-commit hook in subversion), and rebases his changes before dcomitting back carefully, all should be okay.
Quote from: Markohs on March 18, 2014, 04:16:24 PM
I'm okay with developing only in svn, but, in fact it's my prefered option for the develompent environment. But isn't possible to have a git-svn repo, someone keeps up to date with svn, as https://github.com/aburch/simutrans (https://github.com/aburch/simutrans) does now, and make it *also* able to accept pull requests from other people, and *also* capable to push those changes *into* svn?
That would be ideal. However, as fas as I understand, git-svn cannot push merges to the svn. Any pull request from somebody at github would need to be rebased to the svn-head before dcommitting. Which kills the advantage of this workflow. I do not know whether this would be possible without direct access to the local repository containing the git-svn.
Quote
The github repo being named https://github.com/simutrans (https://github.com/simutrans) makes a lot of sense to me.
It would be https://github.com/simutrans/simutrans then.
Quote from: Markohs on March 18, 2014, 05:05:30 PM
About the git issue... As you wish, we can allways give it a try, having backups and we'll have we can allways sort it up is we get a mess anytime.
Going back to a backup would only mess things up more. In a sense, it's not the master that gets messed up if you rebase in a public repo, it's all the clones, because they are not rebased as far as I understand it. From what I've heard/read, rebasing is done locally on your own computer before anyone else sees what you're doing.
Quote from: Ters on March 18, 2014, 06:39:00 PM
Going back to a backup would only mess things up more. In a sense, it's not the master that gets messed up if you rebase in a public repo, it's all the clones, because they are not rebased as far as I understand it. From what I've heard/read, rebasing is done locally on your own computer before anyone else sees what you're doing.
Yep it's local, but if after the commit to svn, he see he has messed up, he can allways go to svn, rever that update, and commit straight in svn again, reverting the changes.
Quote from: Dwachs on March 18, 2014, 06:37:13 PM
That would be ideal. However, as fas as I understand, git-svn cannot push merges to the svn. Any pull request from somebody at github would need to be rebased to the svn-head before dcommitting. Which kills the advantage of this workflow. I do not know whether this would be possible without direct access to the local repository containing the git-svn.
You know better than me git!
I just read http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion and looked like doable, not very hard, but I guess we can just use subversion and leave github as a RO copy, as it's now.
Quote from: Markohs on March 18, 2014, 06:52:32 PM
Yep it's local, but if after the commit to svn, he see he has messed up, he can allways go to svn, rever that update, and commit straight in svn again, reverting the changes.
Then I misunderstood you. Since you wrote "administering the git", I thought you meant the main git repo, that pulls from svn and which everybody clones (and further makes pull request against). That repo can "never" go back. What each person does to his personal git clone of svn is none of our business. They can't commit back to svn anyway, except our core developers, but they don't seem to like git anyway.
No, I was refering exactly to what you expressed. Why can't that git repository, which everybody cloned and can receive pull requests, get svn updates, and push them back to svn when the admin desires so?
And, if he really messed things up, and the mess ended in svn too, *given he also has direct access to svn*, can't he fix the mess in svn, commit, and receive the "fix" in his git again?
I think the stuff in simubase is obsolete and what has not been allowed to be used due to copyright is not missed any more.
When building the SVN it was made from importing the ZIP files from 84.22.1 to 99.00 or so. Until that any release was one revision, and the author was wrong anyway (it was tron, since he ran the script). As such, I am not overly worried about loosing revision numbers (or if importing to svn on sf rather offsetting them with the current on).
As this years seems to get very busy my contributions to simutrans will be less. I could live if we switch to github. I will fight with git too ... (Probably I will be back to submitting patches, but why not).
Git also has a revision number. git describe on github simutrans gives you:
"v111.3.1-1238-g320599e"
v111.3.1 is the last tag, 1238 is the number of revisions since then and 320599e is a unite nubmer which can be used for network identification. Hence user would report revision xyz of v111.33.1 nightly, which is also fairly unique. One coudl even put hte whole strong in the title.
Quote from: Markohs on March 18, 2014, 03:13:37 PM
It's also very important we have mirrors outside isaac's servers, because you never know what can happen to his ISP, and we have to have a plan for those situations, even if they are extremely unlikely to happen.
I'm all for external mirrors/backups, but just to note here that my server is in a datacenter; and actually I still have regret for that period of time I pushed hosting Simutrans away; I managed to keep the server during that mess, I just thought I wouldn't. :/
But iWeb.ca is a strong and stable company, and I've had nearly zero downtime during the months-shy of ten years I've been with them.
But again, backups and mirrors are always a good thing :)
Quote from: Markohs on March 18, 2014, 09:26:36 PM
No, I was refering exactly to what you expressed. Why can't that git repository, which everybody cloned and can receive pull requests, get svn updates, and push them back to svn when the admin desires so?
Because, as I understand it, if you rebase something that others have cloned, then all clones get out of sync. They have to start all over with a new clone, if they have pulled the rebased changelists before they were rebased. http://stackoverflow.com/questions/2715085/rebasing-and-what-does-one-mean-by-rebasing-pushed-commits seems to support my understanding of things.
Since committing back to SVN seems to require rebasing for everything but the most trivial cases, we can't have a public repo do syncing back to SVN. Furthermore, I don't think we can have changes go from a public git repo and back into SVN in a tidy fashion, except by making patches in Git and apply them to SVN, but then the development branches in Git would just lead to nowhere, with the changes just "suddenly" appearing on master.
Contrary to some rumors I'm not dead.
The DNS name for the server went away some time ago.
I was only informed about this by prissi on Friday (14.3.).
I had a busy weekend, so I read this email along with Dwachs' email, which he sent on Monday (17.3).
If somebody had told me earlier, I would have corrected the problem earlier.
The server is perfectly fine, there is just no DNS name for it currently.
Hopefully I get a new name for it today.
I'm going to play with this and see if I can get it working:
https://haanenterprises.com/2013/04/host-your-own-dynamic-dns-using-php-and-cpanel-apis/
Basically, if I can, I might be able to offer dynamic DNS if clients can schedule to run the scripts for Linux or Windows on their end...
Quote from: Tron on March 19, 2014, 01:31:00 PM
Contrary to some rumors I'm not dead.
I've seen one other open source software site disappear from the face of the Internet without explaination in the last four months or so. Now it looked like it was happening again. And death was only one of my possible explainations for why a site would disappear, not that the others were happy endings either. Simutrans has also seen key people more or less disappear for extended periods before.
In my experience, servers on a dynamic IP (in other words at home) have a high tendency to cause worries. I left a Linux box back at my parents place so that I can synchronize backups back and forth. Some times, this has failed to notify me of it's new IP. Another time, the broadband router's entire configuration was inexplicably reset, shutting off port forwarding. If I had this server at my place, it wouldn't have been as hard to fix, but one the other hand, I wouldn't have noticed. The last time, the router simply choked on something, which seemed to affect inbound connections more than outbound.
And sudden death is still a possibility, so it's best to have something in place that makes us not too dependent on any single person. Even if we were to host the repo on Isaac's server, and others have access to that server, it would make no difference if we're not aware of his unability (for whatever reason) to pay the bills before the ISP terminates the server. We need a backup regime.
I'm still having issues installing the svn server in Isaac's server, the mixture of CentOS and cPannel make things harder. The repo works, but as soon as first commit is done, tortoisesvn stops being able to see history.
The only option taht works on CenOS is running the daemon as root (as it's shipped), something I won't do for ethical reasons.
On my personal server, running Debian, the same exact setup, works perfectly.
I'm still on it, but I think the best option is leave Isaac server as the definitive hosting for our subversion. We've had some black days in the past (even I'd say that for being a home server, the uptime has been quite high). dyndns, even being cool, and an nice option, makes no sense when we can host it in a more permanent machine.
But this is, of course, just my personal oppinion.
Just for the record, I'm grateful that tron has provided SVN for us so far. We've gotten that service for the meager price of one great transport simulation game. I'm glad it's not me having to provide these things.
Reading Ters, well, I want to express the same idea. I'm very grateful to Tron for having keep the server alive for so long, and his efforts.
It's just I think the server needs to move to a more stable place, for the good of the project.
I'm grateful to so many that have put in so much effort. Many have put in much more effort than I have, yet as forum admin for a while (now one of several), I got more public praise. So I feel especially desirous to echo in on this as well. There's a lot of effort put in that's not easily seen, but it's still part of Simutrans.
The server has a new name now. You have to update the URL in your working copy. Use:
svn relocate svn://tron.homeunix.org svn://tron.yamagi.org
I'm sorry this took so long. I was notified quite late and then it took a few more days to get a new name.
Maintaining the server is little effort. I'm doing this since 2006. There is no problem doing this further. Except for some rare DNS hiccups or me fumbling an update of the box, I hope the service provided was satisfactionary. I can also provide a git repository instead, if this is desired.
I change the nightly-build-server and hope, that it work next night (when there is a new version)
Turns out I had also a server set up in svn.simutrans.com .
Isn't this a more sutable URL than the one you exposed?
EDIT: I can give you access to the server if you want to setup the server youself, but imho, that URL is not a good one, because it's from a random domain in the internet, and given we already have simutrans.com registered, and servers the community is paying for, makes no sense hosting the repo outside.
It's not that I don't trust your servers or your work, I just want to say the situation should change. I appreciate your work, and thank you, but that URL is bad imho, the server should be *.simutrans.com, or hosted in sourceforge or github.
Why linking simutrans with yamagi.org?
EDIT2: svn://anon@svn.simutrans.com/simutrans
The developers accounts are not created yet, since I just asked tron to restore our current devels passwords himself.
I have a working Dynamic DNS service in progress - I got it working for the first part, but instead of, e.g., subdomain.simutrans.com, it would allow me to assign, e.g., subdomain.simutrans.com with the ability to create/update something like dynamic.subdomain.simutrans.com - i.e. it's one too many steps, because the script I started with had that in mind.
I'm generally in the process of refining it to allow me to delegate somesubdomain.simutrans.com and allow for a URL containing a user/pass to update the IP (either explicitely in the url or implicitely from the machine so connected). It'll take me a little bit because now what I'm doing is starting over with my own script, rather than modifying the one I found.... :) But the principle works.
tl;dr: I will soonish have dynamic DNS working such that anyone who can schedule a URL (curl, for example, or I don't know what else will work, but that's pretty simple) would be able to update with a carefully crafted URL
I'd much prefer if the repository could be moved someplace with a static IP, or atleast to somewhere that doesn't go down every evening to change it...
Quote from: Markohs on March 20, 2014, 03:29:47 PM
or hosted in sourceforge or github.
free today, gone tomorrow.
...Speaking of sourceforge, anyone have a svn dump backup of all the paks stored there?
if they are still online the repo can be replicated vía svnsync, Turfit. Emailing you the pass in svn.simutrans.com
Quote from: Markohs on March 20, 2014, 03:29:47 PM
It's not that I don't trust your servers or your work, I just want to say the situation should change. I appreciate your work, and thank you, but that URL is bad imho, the server should be *.simutrans.com, or hosted in sourceforge or github.
Nobody had a problem with the URL for more than seven years.
Quote from: TurfIt on March 21, 2014, 01:00:08 AM
I'd much prefer if the repository could be moved someplace with a static IP, or atleast to somewhere that doesn't go down every evening to change it...
Due to the IP change it's not available for about two minutes in the middle of the night.
So that's what you get for hosting the server for more than seven years. *shrug*
Quote from: Tron on March 21, 2014, 05:10:36 AM
Nobody had a problem with the URL for more than seven years.
I think Simutrans has grown over time, with more and more people becomming aware of it. And I have always found it strange that the main source repository is on some unrelated URL I can never remember. When we have to change it anyway, it seems more tidy to switch to a Simutrans domain, rather than another "random" unrelated URL.
Quote from: Tron on March 21, 2014, 05:10:36 AM
So that's what you get for hosting the server for more than seven years. *shrug*
I just don't feel good when someone reports a bug in the latest nightly and I have to tell that player that I'm unable to look into it because I don't have the code for that nightly since a server hosted by someone I don't know how is has disappeared and no one knows what has happened or how long it will be until we can help.
Quote from: Ters on March 21, 2014, 06:02:01 AM
I just don't feel good when someone reports a bug in the latest nightly and I have to tell that player that I'm unable to look into it because I don't have the code for that nightly since a server hosted by someone I don't know how is has disappeared and no one knows what has happened or how long it will be until we can help.
Wow, just wow. Nobody told me for more than a week! I probably could have resolved the issue within a day, just if somebody had written me that there is a problem in the first place.
There was a problem, I'm sorry for that. I resolved it as fast as possible when I was informed. But you seem to be so eager to get away, here's a full dump of the repository: http://tron.yamagi.org/simutrans.svn.dump.xz (http://tron.yamagi.org/simutrans.svn.dump.xz) (That's what I originally promised to prissi: If he ever does not want my service anymore, he'll get a full dump, no questions asked.)
Hey, sorry for hijacking this
hot topic.
Quote from: Ters on March 21, 2014, 06:02:01 AMI just don't feel good when someone reports a bug in the latest nightly and I have to tell that player that I'm unable to look into it because I don't have the code for that nightly since a server hosted by someone I don't know how is has disappeared and no one knows what has happened or how long it will be until we can help.
Ters, bad things happen, sometimes, once in every 7 years. ;)
And as Isaac said, it's good to have mirrors.
Quote from: Tron on March 21, 2014, 05:10:36 AMSo that's what you get for hosting the server for more than seven years. *shrug*
IMHO, you should post a few more on this forum. To me you have been a legendary or nearly-mythical figure on this community. Not that you owe us something, on the contrary(!), just for friendship reasons. We on this side barely know you.
Quote from: IgorEliezer on March 21, 2014, 06:54:11 AM
IMHO, you should post a few more on this forum. To me you have been a legendary or nearly-mythical figure on this community. Not that you owe us something, on the contrary(!), just for friendship reasons. We on this side barely know you.
Sorry, I'm hardly involved in Simutrans development anymore. I worked on it a bit, but that's quite some time ago. Accordingly I haven't visited the forum in a long time. Now my only contribution is running the repository server, which I'll gladly continue to do. But there seems to be a strong sentiment against this. So I provided a dump of the repository.
You are taking it personal, Tron, and it's not that way.
It's just about the dynamic DNS, and having a URL related to simutrans, those are objective reasons. It's not that we don't respect and appreciate your efforts. I offered you setting the repo yourself in the server, and you didn't answered.
About the dump, thank you, may I have also the hooks you were using on the repo too, please? I'd also like to have the passwd file, if possible, but by PM, don't post it here because it might contain sensitive information, ofc.
Quote from: Markohs on March 21, 2014, 10:14:36 AM
You are taking it personal, Tron, and it's not that way.
What is this? I explicitly said I have no problem, if you want to move the repository elsewhere. The consensus of this thread seems to be, that you want exactly that. So I gave you the dump, which I promised Prissi years back. I Handled this professionally and now you claim I'm taking this personally. You plain make no sense.
QuoteIt's just about the dynamic DNS, and having a URL related to simutrans, those are objective reasons. It's not that we don't respect and appreciate your efforts.
Are you aware, that DNS has absolutely nothing to do with the server itself?
QuoteI offered you setting the repo yourself in the server, and you didn't answered.
Huh?
<edit>Oh, you wrote a private message. Didn't see that.</edit>
Okay okay, no problem then, I misunderstood you maybe.
I know the difference between a server and a dns entry. But DNS affects the reacheability of the *service*, that's what we had problems with, and the core of the issue.
I can update any DNS entry, if I have the necessary credentials. Obviously I do not have them for simutrans.com subdomains. I'm sorry that the old name went away. So I had to use another one, which I'm confident will not make any trouble. I'm sorry that it took so long, mainly because I wasn't aware for quite some time, that there is a problem.
About your private message: I'm not going to administrate a server I have no control over. This just begs for trouble, which I can do nothing about, but I will get the blame for.
Okay then, Tron. :)
Can you send to me the hook files to see how did you had it configured, please? Or at least the important details. The passwd file whould be useful too, if you feel comfortable sending it to me, vía PM, please. Or I'll need to assign new passwords to everyone. Also, if you want access to the new server, send me your desired password, or if you want me to generate a new one for you.
Hey,
at now, is svn://tron.yamagi.org the official SVN or not? SVN was 2? Week offline and when it is online (2 Days?) there is no checkin?
Greeting,
Werner
Quote from: wernieman on March 21, 2014, 08:34:35 PM
at now, is svn://tron.yamagi.org the official SVN or not?
I've been wondering the same. There seems to be a complete lack of coordination at the moment.
Well, like all subjects related to simutrans I guess we'll have to wait for prissi or dwachs to have rheir say. But reading past comments, svn.simutrans.com its suposed to be the official one, since has a static ip, it's hosted in the community server and has a url that makes sense.
Ok, aparently a bad time for being really busy in real life ...
URLs are flexible. svn.simutrans.com can easily forward to tron.yamagi.com or whatever. So the name is not needed to be connected with any service.
I could not relocate to the new svn when I tried yesterday, since mingw and SVN clashed for my installation. I could resolve this today. If I find some more time this weekend, I will check some stuff in.
Personally I am absolutely not maintaining a SVN server. My knowledge of that is zero. Tron has much more IT knowledge (servers, SVN, OOP) than myself. The loss of DNS is something completely out of his control.
I am conservative, I do not like to touch things that are working. Trons SVN was it for more than seven years. Apart from current event and a similar occasion (that time only two days) years ago, the SVN server failed less than sourceforge. In that time we lost the forum twice and were hacked once. Sorry, to put it this way but I am not convinced an SVN on Isaac server is more stable. Hence I would be happy to keep it with Tron as the SVN server part (and the hooks) did work well.
But then my time to devote to simutrans has been less and less and hence my word carry less weight.
I'm with prissi, I think Tron's server is stable, that's the first time I saw this happen. We can point svn.simutrans.com to Tron's server and have a 'beautiful link' for our SVN.
Whatever the consensus you reach, please don't forget to set a backup policy somewhere else. This time nothing happened, but what if it had happened...
Okay then. Isaac, then you can delete the installation when you wish so.
Quote from: Tron on March 21, 2014, 05:10:36 AM
Due to the IP change it's not available for about two minutes in the middle of the night.
If it was two minutes in the middle of the night, it wouldn't be noticable. However it's been more like 60-90 mins every evening given the time zone differences. But, tonights IP change was much quicker - perhaps whatever yamagi.org is works better than dyndns...
Quote from: prissi on March 21, 2014, 11:26:15 PM
the SVN server part (and the hooks) did work well.
What are these hooks supposed to do? Every time I commit an error about a failed post commit hook comes out, but since the commit itself shows up, I've ignored it.
Quote from: TurfIt on March 22, 2014, 02:15:09 AM
If it was two minutes in the middle of the night, it wouldn't be noticable. However it's been more like 60-90 mins every evening given the time zone differences. But, tonights IP change was much quicker - perhaps whatever yamagi.org is works better than dyndns...
That's probably related to the time-to-live on the DNS record. This tells how long secondary DNS servers (and possibly end users) can cache the result of a query. A high TTL means that the primary DNS server doesn't have to handle as many queries, but if the IP changes, it will take some time for that change to become apparent to everybody. A low TTL reduces the propagation time of an IP change, but the primary DNS has to handle more queries.
I have noticed that the Github mirror has not been updated in quite some time - is that a problem with the Github mirror, or is that because the SVN has not been updated recently? The last update registering on the Github mirror is 20 days ago.
I guess it's because however administers the github mirror doesn't know what the new url is. I don't.
Hmm - the Github mirror being down does cause problems for merging Standard into Experimental. Are there any plans to fix the Github mirror?
Quote from: jamespetts on March 22, 2014, 11:41:15 AM
Are there any plans to fix the Github mirror?
Preferrably not until we have decided on how to resolve the SVN issue.
Quote from: wernieman on March 21, 2014, 08:34:35 PM
svn://tron.yamagi.org the official SVN or not? SVN was 2? Week offline and when it is online (2 Days?) there is no checkin?
I would vote for YES
Switched my working copy with
svn switch --relocate svn://tron.homeunix.org/simutrans/simutrans/trunk svn://tron.yamagi.org/simutrans/simutrans/trunk
Quote from: Ters on March 22, 2014, 11:51:29 AM
Preferrably not until we have decided on how to resolve the SVN issue.
Ahh, I see. As long as it is fixed in the end, all will be well. It is good of Tron to have maintained the SVN so long, and of everyone else to have spent so much effort in seeking to have it fixed. Simutrans is a splendid community.
Quote from: Dwachs on March 22, 2014, 11:57:35 AM
Switched my working copy with
svn switch --relocate svn://tron.homeunix.org/simutrans/simutrans/trunk svn://tron.yamagi.org/simutrans/simutrans/trunk
If the command I gave above didn't work for you, you must have a very old version of svn. svn relocate was introduced more than two years ago with svn 1.7.0.
I have svn 1.6.x installed ...
Took the freedom to commit some fixes and tweaks to the relocated repo. Thank you tron for your help!
Could we agree on using tron.yamagi.org as repository?
Would it be a good idea to forward svn://svn.simutrans.com to tron's repository?
I deleted svn.simutrans.com repo yesterday. There is nothing more to agree on
Quote from: Dwachs on March 22, 2014, 03:07:29 PM
Would it be a good idea to forward svn://svn.simutrans.com to tron's repository?
Why not? Nobody else is using that domain. It also makes it easier if the repo has to change domain later.
Quote from: Ters on March 22, 2014, 04:04:24 PM
Quote from: Dwachs on March 22, 2014, 03:07:29 PM
Would it be a good idea to forward svn://svn.simutrans.com to tron's repository?
Why not? Nobody else is using that domain. It also makes it easier if the repo has to change domain later.
+1
If you doubt about Isaac's community founded servers stability and security maybe this is not the brightest idea, adding double failure points. But well, it's acceptable if it's just a CNAME the risk is low. Anyway, do as you wish, I've wasted more time here than I should have.
I was thinking just a CNAME. If we lose simutrans.com or the DNS for its subdomains die, the SVN domain can still be accessed directly, as long as we remember what it is. That last part is probably the only drawback of having a svn.simutrans.com redirect.
So, can we create the CNAME?
How ironic that simutrans.com (the domain name itself) was down earlier today. At least for me.
I ended up with a few issues during the server moving process.
I'm on what they call a "SMART" server now - I think if I need to move servers again, all they have to do is move the VM-that-takes-the-whole-server to another server, i.e. no changes, just faster hardware after a quick copy..... :)
But basically, I screwed up DNS and had to fix it and didn't realize until it was already a problem, of course. d'oh
Hi all,
a few years ago I made for our customer a very simple dyndns server - compatible with most dyndns.org clients (tuned with inadyn). It is a simple PHP script translating the requests from GET/POST to nsupdate. It would allow us to have the svn.simutrans.com record pointing directly to the svn, without relying on any public dyndns services. Interested?
LS,
I have setup my development environment using msvc and the integrated git support on that.
But since the move of svn the git copy is not updated anymore (latest version on git = 7096, dated march 2).
Will the regular update of git be reinstated shortly ?
Kind regards,
Herman
Quote from: hreintke on March 27, 2014, 03:55:19 PM
LS,
I have setup my development environment using msvc and the integrated git support on that.
But since the move of svn the git copy is not updated anymore (latest version on git = 7096, dated march 2).
Will the regular update of git be reinstated shortly ?
Kind regards,
Herman
Interesting - I was not aware of the integrated Git support in MSVS. Is that in the Express version, or only the paid for version? If in the Express version, may I ask where one can look to have it set up?
Incidentally, I agree with Herman - it would be very difficult if the Git support was not restored.
Who runs the Git everyone is using anyway?
James,
I am using git with the express (= free) edition of msvc 2013.
Quote from the site "Note: Visual Studio 2013 includes Git tools by default so these tools are not needed. Learn more on MSDN: http://msdn.microsoft.com/en-us/library/vstudio/hh850437.aspx".
But with git plugin I also used it with msvc 2010.
Herman
Quote from: Ters on March 27, 2014, 05:25:17 PM
Who runs the Git everyone is using anyway?
ansgar / aburch. Will send him a PM / email.
Quote from: Dwachs on March 28, 2014, 06:59:23 AM
ansgar / aburch. Will send him a PM / email.
Did you hear back from Ansgar? I worry somewhat that he is no longer available, as he has not responded to communications that I sent some time ago about the automatic Linux builds for Experimental being down. We might have to look into alternatives for Git hosting.
It just shows the risk associated with relying on someone outside the project. With Git, as opposed to with Subversion, I think Experimental should have its own Git. It will pull from some official Simutrans Standard repository, be it an official Git mirror or directory from SVN, but not push.
Experimental does have its own Github repository, but relied on Ansgar's Git mirror of Standard for merging, and separately on Ansgar's automatic builds for Linux.
There's a git mirror at git://tron.yamagi.org/simutrans (http://forum.simutrans.com/git://tron.yamagi.org/simutrans).
Would it be possible to magically post-commit from the svn to the github mirror (or a fork thereof)? Ansgar/aburch seems to have disappeared.
My git mirror is updated automatically after each svn commit. It's a post-commit hook of the svn repository. I cannot update ansgar/aburch's repository, because I do not have access rights for it. What would be the point anyway?
The point is that there is a simutrans fork on github (James Petts' simutrans-experimental) that has its development based on the github mirror aburch/simutrans. I could set up a fork of aburch/simutrans at simutrans/simutrans.
Would it be possible to push per post-commit to such a repository? I do not know if git-svn could handle this automatically.
I have heard back from Bernd Gabriel, who has managed to fork from Tron's Github repository: thank you both to Tron and to Bernd for setting this up. Bernd's own Github mirror is here (https://github.com/BerndGabriel/simutrans-experimental/tree/standard).
That is nice. Is there any chance to move this repository to the simutrans organization at github? This way it would serve as an official mirror with a nice address.
I do not know about moving it, as it is part of Bernd Gabriel's own mirror, which he uses for his own development work, but perhaps it could be re-mirrored?
ansgar made the mirror working again.
Ah, splendid!
Quote from: Dwachs on April 06, 2014, 02:45:04 PM
anger made the mirror working again.
That's how I misread it, anyway. It's too early in the morning. lol
That's what happened Isaac, Dwachs opened git and yelled "WORK!", and it worked.
Quote from: An_dz on April 06, 2014, 03:52:43 PM
That's what happened Isaac, Dwachs opened git and yelled "WORK!", and it worked.
As I had read only the Isaac's quote, I had a mental image of a guy yelling "WORK!" at an actual mirror in the bathroom...
Science has gone so far......
Tron's new svn repo is ok but I have problems with svn repo on sf.net now. I can't checkout pak128. It says:
svn: E210002: Unable to connect to a repository at URL 'svn://svn.code.sf.net/p/simutrans/code/pak128'
svn: E210002: Network connection closed unexpectedly
and sometimes third line is
svn: E210002: Can't connect to host 'svn.code.sf.net': Connection refused
I have tried it for last three hours... No change...
Is it my fault or have you problems too?
That repo works for me now, except that I use the http protocol. Might be a temporary outage, or the svn protocol is discontinued.
Sourceforge had more SVN issues over the year for me than trons repo ... Since snv and http goes via different front end servers (as far as I understood) it may as well be that only one of them has sone issues.
I have been trying to follow up on posts to get the SVN working, but no luck so far.
Can someone please post the current SVN repository link to use?
Repository Root: svn://tron.yamagi.org/simutrans
Thanks, is this the new permanent address?
Should be
Seems like the SVN is offline again.
svn: E000061: Can't connect to host 'tron.yamagi.org': Connection refused
When trying tron.homeunix.org (as described on simutrans.com) the same error occurs.
It's been that while since at least the 9th, when Dwachs sent a message to the hoster.
it is working again
The machine didn't restart after somebody caused a power outage by cutting a live wire.
I wasn't there before the weekend to correct the issue, sorry.
Can someone adapt the link to the old svn repo location at:
http://www.simutrans.com/en/develop
I already updated:
https://www.openhub.net/p/simutrans/enlistments
And maybe someone should also update the git-svn-id (is that possible?), see e.g.
https://github.com/aburch/simutrans/commit/bf2f51bcdb176c5924111c78d12f3945509d2222
at the top of the screen.
thanks for the note.