To the Simutrans github organisation

[Sirius]

*dig*

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?

[prissi]

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 ...

[Roboron]

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 :-)

[prissi]

The svn now uploads itself after each commit to github.com/simutrans/simutrans 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.

[Roboron]

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?

[Sirius]

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

[prissi]

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?

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.)

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

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.

[AlexBond]

It'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.
https://github.com/aburch/simutrans/network/members

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.

[Sirius]

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: https://github.com/irgend42/simutrans

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.

But 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.

[prissi]

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.

[Sirius]

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: https://www.simutrans.com/en/develop/

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.

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)

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.

[Roboron]

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.

That is quite inconvenient. Not a realistic solution.

In 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?

[Sirius]

I 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.

[prissi]

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.

[Sirius]

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.

[prissi]

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.
 

[Sirius]

Well it's not only the author and committer name/mail, but also the commit message.
aburch was set up with svn://tron.homeunix.org/simutrans/simutrans/, you have set it up with localhost whilst mine is using svn://servers.simutrans.org/simutrans, 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.

[prissi]

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: https://chapmanworld.com/2018/08/25/why-im-now-using-both-git-and-subversion-for-one-project/ )

Keeping the hashes will not be trivial.

EDIT: THese commits are broken in aburch

Code Select Expand

empty in both (ok)
274
671
681
1430
1491
2681
3105
3829
4961
broken (empty) in aburch
616
629
664
665
672
674
693
695
700
702
712
714
715
724
726
727
737
738
740
741
749
751
755
759
760
761
764
766
770
777
778
783
785
795
801
802
804
805
808
809
851
886
1160
1181
1216
1228
1249
1309
1320
1325
1342
1348
1367
1373
1388
1389
1425
1454
1612
1630
1641
1648
1694
1710
1713
4841

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)

[Roboron]

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.

You can add more emails on https://github.com/settings/emails

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)

So, if we are serious about the github repository, the solution is to actually delete (or stop) the aburch mirror, isn't it? We have to ask aburch to stop the aburch/simutrans mirror, upload the aburch repository to simutrans/simutrans, and then we can continue from there since there won't be a problem of mismatched commits.

[Sirius]

I am not sure about this.
Why do we need aburch to upload his repo to simutrans/simutrans?

[Roboron]

I am not sure about this.
Why do we need aburch to upload his repo to simutrans/simutrans?

Not his repo, but a copy (or a fork, however you want to call it). To maintain previous commits hashes intact, while allowing us to keep going our own way in the future.

[prissi]

But the aburch repo history is broken. Why should be upload a broken history?

[Sirius]

Fork won't work. Clone seems to be the right concept here.
Which repo exactly do you mean?
aburch/simutrans or his local repo?
I don't think we need aburch to do anything to get a clone of his repository set up.
See https://github.com/irgend42/simutrans and the corresponding https://github.com/irgend42/git-mirror/blob/main/.github/workflows/sync.yml which does the hourly mirroring.

[prissi]

Aburch repo is broken, its commit history is damaged, for whatever reasons. That cannot be a proper base for anything. Let's remove aburch, before more harm is done. In git one can rebase repos, if I read my documentantation correctly. Or jsut copy one's current state onto whatever git checkouy produced.

Moreover, I doubt extended has really any interest in standard fixes apart from ranran. I spent some days to have the file reorganisation to be done via a script, but extended seems to have no intention to follow that and has consequently drifted further apart. With the split of several files, there is almost no way to port fixes between these version any more without lots of manual work.

[Roboron]

But the aburch repo history is broken. Why should be upload a broken history?

Because everyone else is using aburch's broken history, aren't they? They need the history to be consistent, even if it means it needs to be consistently broken (?)

Aburch repo is broken, its commit history is damaged, for whatever reasons. That cannot be a proper base for anything. Let's remove aburch, before more harm is done. In git one can rebase repos

If that is true and any fork that wants to can rewrite its history as will with simutrans/simutrans history, then I shut up.

I don't think we need aburch to do anything to get a clone of his repository set up.

No, we don't. But we would need for aburch to stop so both repositories don't end up unsynced again.

[Sirius]

I don't think missing commit messages on a hand full of commits is quite harmful nor an issue you cannot base any work on. That issue was not even noticed until recently.

Anyways, moving the master over is as simple as

Code Select Expand

git remote add simutrans https://github.com/simutrans/simutrans.git
git rebase simutrans/master
As both should practically hold the same code, there won't be any conflicts.

Rebasing an actual fork as OTRP or simutrans-extended or a long living feature branch that had already fixed some merge conflicts will be much more troublesome though.

We shouldn't mind too much about aburch stopping his mirror or not.
It really doesn't matter pretty much.
Especially as commits are still submitted to the svn via patches, the commit hash doesn't matter at all.

[prissi]

I cannot move the master over, as extended was/is part of simutrans/simutrans. Not allowed by github.

[Sirius]

GitHub won't stop you from doing the above.
This is not about moving the fork (a GitHub-level concept) to the simutrans organisation, which GitHub would actually reject.
It is about rebasing the codebase (a git-level concept) to the same state as aburch/simutrans, so both share the same commit history without being considered a fork by GitHub.

Edit: Even better, as both branches should share the same code, you don't need to rebase.
Ensure that you have no local uncomitted changes, then you can simply reset your master to aburch/simutrans:

Code Select Expand

git remote add simutrans https://github.com/simutrans/simutrans.git
git checkout master
git reset --hard simutrans/master
Then validate if you can still pull changes from the svn. If this works, do

Code Select Expand

git push --forceOtherwise you can still roll it back

Code Select Expand

git reset --hard

[[C] Ranran]

With the split of several files, there is almost no way to port fixes between these version any more without lots of manual work.

The same is true vice versa. As mentioned earlier, migrating to a new folder structure makes cherry picking from old standards commits impossible and must be manually merged. There are many commits that haven't been incorporated  yet. For example, we need to fix a broken multi-tile city building code brought by THleaderH. The overtaking code also has bugs, but he himself has no intention of fixing those. Climate patch could be incorporated somewhat.

Moreover, I doubt extended has really any interest in standard fixes apart from ranran. I spent some days to have the file reorganisation to be done via a script, but extended seems to have no intention to follow that and has consequently drifted further apart.

It takes a lot of time to merge from the standard. Coders who do that are somewhat familier with both standard and extended, and changes may produce errors if they don't understand the differences in the specifications. Of course the most appropriate people for these would be prissi and James, but for them to do so would slow down the development of standard / exntended.
Even with OPRP, which has a high affinity with Standard, merging from standard seems to be partial. It seems hasn't got more standard commits than extended and still stagnant at 122.
https://github.com/teamhimeh/simutrans/blob/OTRP-KUTAv6/documentation/cherry-picked-commits.txt

Unexpected bugs may occur due to the differences in the code accumulated so far, such as mouse operation bugs and bugs related to the operation of depot dialog. The old-fashioned extended depot dialog, which is not yet scalable, somehow caused a lot of anomalies... Even if not, there are many unresolved bugs in extended.
And it may take a lot of time to fix.
I'd been working on incorporating a new scalable UI system before making major GUI changes as prissi and ACarlotti recommended to me.
However, since my objective in that regard has been largely accomplished, and since I cannot spend a lot of time on it, I have declared that I will not do any more work on it, in the hope that another contributor will do this for simutrans and simutrans extended.
Similarly, there is a lot of UI stuffs that can be backported from extended. Someone who wants to incorporate it can incorporate it into the standard. I do that means I increase the time I consume on simutrans by a factor of three or four. Ideally, however, the stuffs available for both should be common and properly maintained and refactored.

[prissi]

@Sirius
The prime reason for a CVS is to have a correct history. Why should I preserve a broken history. Apparently one can rebase also the individual github forks like that.

@Ranran
I think applying the file movement shell script to extended (just replace svn mv to git mv in the script) would have an almost working extended close to the current standard organization, and all patches could flow more easily between them.

[Sirius]

Suddenly, I have been mentioned on an old post?

I did not reply to this as I think all relevant points have been raised already. Both approaches have their pros and I am not here to make decisions on standard. I'm just here just to clarify technical (im)possibilities that are none, so you can make these decisions by yourself.

[Matthew]

Suddenly, I have been mentioned on an old post?

I did not reply to this as I think all relevant points have been raised already. Both approaches have their pros and I am not here to make decisions on standard. I'm just here just to clarify technical (im)possibilities that are none, so you can make these decisions by yourself.

You probably just got an email now that the email functionality has been restored after being broken.