Want to praise Simutrans?
Your feedback is important for us ;D.

To the Simutrans github organisation

Started by Sirius, October 08, 2021, 10:39:20 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.



Returning on this,
What's the conclusion on the simutrans repositories in the organisations?
I am considering to move simutrans/simutrans-extended back to my own accout as James is back for quite some time and the repository is usually behind james now.

That would finally allow standard to join the organisation.

It might still be desirable to have the active repository of extended attached to either the simutrans organisation on github or its own simutrans-extended organisation.

How should we handle this now?


I think it would be good to be able to have an accessible simutrans github repositorz. However, since the aburch one is anyway just a mirror of an svn, I could also import the svn into a simutrans/simutrans github. As long as the svn still submits to aburch to, extended could still derive merges from it. THat way one could have both.

EDIT: I have set a test hook to push the svn to simutrans/simutrans. That would allow to host bost here. It is private for now until I am sure the hook works as intended ...


Really the problem is just the "fork" status of a project. GitHub does not allow forks to co-exist in the same organization.

But there are no "forks" in git, this is an exclusive concept of GitHub. So the solution is simple: instead of using the "fork" button in GitHub's UI, just upload the repository as it were new.

As prissi said, one could simply import the SVN repository into a brand new GitHub simutrans/simutrans repository, and there would be no problem with simutrans/simutrans-extended, as it is not technically a fork :-)


The svn now uploads itself after each commit to That was needed to have the automated Nightly for Android working anyway, since I have no access to aburch. It has also the added benefit, that any commit to the SVN will be immediately pushed to github.


Fantastic! I was going to suggest it, when I saw the issue of the keys in the other thread :-)

One small suggestion: The aburch repository currently links the SVN accounts to our GitHub profiles, but this new repository does not. Can it be configured the same way?


Should be best to sync this with the aburch git repository, not the svn one.
That way commit hashes will be the same in both :)


Quote from: Roboron on June 22, 2022, 02:57:03 PMThe aburch repository currently links the SVN accounts to our GitHub profiles, but this new repository does not. Can it be configured the same way?
I have no idea how to do this. I was never asked by gitsvn to provide emails. To do this, I need to reimport. (Not a big problem in principle.)

Quote from: Sirius on June 22, 2022, 10:16:04 PMShould be best to sync this with the aburch git repository, not the svn one.
That way commit hashes will be the same in both :)
Impossible. I will rather ask aburch to delete this one, since we have zero control on it and I also cannot push to it.

But I wonder how git can generate different hashes when committing the same code diffs (albeit generated by different versions of git-svn). It seems that git "hash" is rather a random number in that case, since it depends on time!!! (I googled it, since I could not believe this.) My respect for git dropped even lower.  A hash over the same code (no matter who wrote or committed it) should give the same value, otherwise it is not a hash but a random number.

A true distributed system should return the same hash for the same content of the codebase. I highly doubt git would have become so popular without github shielding users from most of that madness. Anyway, resistance seems futile. SO I cannot reproduce the hashes of aburch. Finish.


Quote from: Andarix on October 27, 2021, 05:06:06 PMIt's not much different with Standard. Feedback has generally become very rare at Simutrans, if it has not always been that way.

But you can announce releases and thus enable the distribution among the players.

I also think that the little feedback here comes from the fact that Simutrans is very fragmented on the Internet.

Simutrans has a long fork list. But very few users have ever read here.

And ultimately you also ask yourself whether the behavior of Simutrans / Pakset is an error or whether it is intentional. Since there is little documentation about how what should work, the evaluation is rather impossible for pure gamers. Even players who have been following Simutrans for a long time have problems assessing certain behavior.

And if documentation is available, you can often no longer find it because you don't even know what to look for.

an example
A few years ago it was installed that factories could increase their production. But I never found a documentation of what was intended and how it works. That was probably programmed by Knightly. But whether that was finished or not, nobody knows anymore.

So even if you want to document something, you can hardly find any information about it. In any case, it is very tedious and time-consuming to obtain information.

And so functions that have now existed have probably been forgotten.

There are no lost vehicles, vehicle breakdowns, accidents, disasters, black helicopters, UFOs or economy crashes in Simutrans. After you have set up a well-designed network, it should continue to run flawlessly (except that your vehicles may get stuck in heavy traffic, caused by city cars, or AI players flooding the streets with too many trucks). As cities grow and new factories are added, you - at least - may want to adjust the transport capacity.


Not quite impossible...
Depends on the flow you are aiming for.
Do you want to continue contribution to the svn or to simutrans/simutrans?

In any case, you need to mirror the aburch/simutrans repository first.
Your repository will then look like that:

In the former case, you will simply keep pushing to the svn. To stay in sync with aburch, you will then pull changes from there.

In the latter case, you will stop committing to the svn and will instead commit to simutrans/simutrans directly.

aburch/simutrans will fall behind simutrans/simutrans, but those commits shared in common will remain in common (because they are still the same, not only similar)
Aburch could then set his repository up to mirror back from simutrans/simutrans if he likes to.

In any case, this will make migration easier for anyone who has cloned from aburch/simutrans.

Quote from: prissi on June 23, 2022, 07:54:50 AMBut I wonder how git can generate different hashes when committing the same code diffs
The same code diff is just the same code diff, not the same commit. A commit consits of more than just code. There is also metadata.
That's not quite random. If you feed in the same commit, you'll get the same commit hash. It's just about ensuring that different commits have a different hash.

Edit: Welcome to the Community AlexBond, I suspect the post might be quite off-topic.


git should not be the blockchain. A hash over the same codebase should give the same result on a distributed code system. With svn, I can check out a revision compile it and via the svn revision I am sure the server will stay in sync (unless there are problems in the code). This is not the case with git, same code, different hashes on forks without always hard reset the local repo and loose all branches. Therefore, SVN will be the master until git can somehow solve this problem (so never, I fear). If there was fear of cycling histories, one come add a revision number and a hash together.

And honestly I do not care about github forks from aburch. It was ever considered offcial in any documentation in the first place, and never anything was given back apart from ranran. And as said, the svn can push directly to simutrans/simutrans but not to aburch/simutrans. For any change like to get a special nightly build (like a release) I have to wait between 12-48 h and hope nobody else commits in between. It messes up my workflow, and I am old enough to want software working for me, not the other way round.

It would be great if someones write a distributed versioning system, that is not a bunch of hacked script, with a at least somewhat consistent command line syntax. In the latter mecurial semms already better. Not sure asbout the former.


In simutrans it's always difficult to distinguish between "official" and "community"
Might be, because both is kind of the same?
In any case, aburch/simutrans is mentioned in a number of community-official places, one of these being this page:

Sure, we can just break all those forks, as we don't care about git users, but I am not quite sure whether this might affect contributors moral in a positive way.
I remember a few more than just Ranran that have a fork of aburch/simutrans that made some contribution the good old way via patches in the forums.
One of those being the infamous jamespetts/simutrans-extended fork.

Quote from: prissi on June 24, 2022, 01:28:54 AMWith svn, I can check out a revision compile it and via the svn revision I am sure the server will stay in sync (unless there are problems in the code)
Same for git. If you checkout the same commit, you can be sure it will stay in sync (unless there are problems in the code) because, well... you have actually compiled the same code.
Just the other way round won't work: If someone rewrites history, changing a few commit dates, authors or any other metadata, the resulting code will still stay in sync, but the commit hash is different.
That is quite a good thing for revision reasons and mandatory in a distributed system, as there is no single point of truth.


Quote from: Sirius on June 23, 2022, 05:53:46 PMIn the former case, you will simply keep pushing to the svn. To stay in sync with aburch, you will then pull changes from there.

That is quite inconvenient. Not a realistic solution.

Quote from: Sirius on June 23, 2022, 05:53:46 PMIn the latter case, you will stop committing to the svn and will instead commit to simutrans/simutrans directly.

That would be a solution, if prissi and others developers wanted to use git instead of svn, which does not seem to be the case. Otherwise it would had already happened.

But I wonder: Why does it matter? If you forked aburch/simutrans, you can keep getting updates from that mirror, it is not like it is going anywhere. If you want to contribute to simutrans/simutrans, you still need to submit a patch to this forum, and git hashes do not matter here?


Quote from: prissi on June 23, 2022, 07:54:50 AMI will rather ask aburch to delete this one
Reads like there might be some intention to remove it, in which case all git users either had to update their local repositories from the svn or they had to migrate to the new one, which is possible.
Possible, but not quite much fun to rebase to a different code tree.

Anyways, what's the exact intended workflow with the svn repository and git?
That's just two examples of working solutions to a yet not quite well defined propblem.


The SVN is intended as the main repository, providing the revision number and being almost indestructible by command line use. Also easier to use on the commandline.

Github is mainly used as a CI built environment. And thanks to simutrans/simutrans we could at least recieve pull requests, which was not possible before.

If I commit something to github to initiate a pull request, which is then merged into the svn, the hash of my git repo after merging exactly the same code from aburch is not the same as on aburch. Why should metadata matter as long as the code is the same? It is not the blockchain, one has commands to rewrite git history. Of course I could write a script that hashes over all cc and h files before each compile to make uniques hashes for each code revision, but exactly this should be the task of a proper version control system.

It is more clear with revisions to find the point in history when things broke. Working up to revision xyz is much easier than hash xyz, especially when local hashes and github hashes differ with throwaway branches.

When we lost admin access to the second SVN, the commits were one by one pulled from the svn and pushed to the new one. Mo problem, each revision stayed the same. With git all these would have different hashes despite being verbatim code and commit copies apart from timestamps.

On Pull requests: I find it very unlikely that I would merge a pull request without some changes, like indentation, comments. or more often also fixing side effects. So verbatim pull request I would do from ranran, and other developers, but not from newbies. Not out of spite, but just because simutrans is so large, side effects are quite likely. And having separate commits for a feature and next the bug fix for that feature is not so nice (but still happens plenty of times.) And it will waste my time, since I saw the problem during code review.


I'm skipping those comments about the so-called "improper version control system" as being highly opinionated and partly incorrect.
There seem to be unresolvable merge conflicts in our opinions on git. Unlike most other such merge conflicts, it seems totally fine to leave this unsolved.

So let me get back to the issue: We'd like to have a git mirror of the svn that has the author name/mail mapped correctly and, in a perfect world, also is consistent to aburch/simutrans.

The good news is, all the information required to get this working is in the svn and we can setup a mirror whose commit hashes will match those of aburch/simutrans.
The bad news is, my connection to the svn is god **** slow, so I might hopefully see if the author mapping has worked tomorrow morning...

If it did, the commits should match those on aburch/simutrans.


If these commits are identical hashwise, then I retract my comments about the time entering the hash.

Since the master git repo the svn is pushing to is on the svn server (or else the svn cannot push to it), I need to replay it on the svn, where it only takes half an hour. Otherwise the next commit would have another mapping file again.


Well it's not only the author and committer name/mail, but also the commit message.
aburch was set up with svn://, you have set it up with localhost whilst mine is using svn://, so that also needs to be fixed to make things work.

But then, it really should work.
I did some git operations on my local clone of simutrans/simutrans and indeed, after amending the commit message and author name/mail, the commit hash was the same.

The repository name is a svn thing. I couldn't find out how to change the name in a quick run but that shouldn't be an issue.
In the worst case I can make a small script to amend all commit messages, but I am quite sure there must be a better solution.


Ok, using rewriting root at the init does the trick only half way, because the commit messages in aburch are broken, i.e. occasionally empty after r616,629,... So any revision after r616 will have a different hash with the correct commit messages.

Ok, 75 empty commit messages. These can be not related to removing pak64 from svn histroy, since these commits also changed other files. Since I got the original svndump from tron, I suppose this means that the script aburch was using had issues at these commits.

(On a side note, my issues with git are nicely summarized here: )

Keeping the hashes will not be trivial.

EDIT: THese commits are broken in aburch
empty in both (ok)
broken (empty) in aburch

Also the nice feature of collection contributions works only for emails on github. So any email added before (like mine and Dwachs) will not show on github., and the svn message still shows the wrong svn These are some compelling reasons to forget the old hashes of the broken aburch repo, or at least change this after a certain commit on simutrans/simutrans (if possible)