To the Simutrans github organisation

[Mariculous]

Sorry, but I really couldn't find a suitable place for this in the forums...
It seems like James is currently on a hiatus and he's the only one able to accept commits to his repository, which is currently the official repository of simutrans extended.

To circumvent this issue for now and in the future, we (Well namely Freddy and me) would like to maintain a repository owned by the simutrans organisation.
For now, I have simply shared access to my repository with Freddy, but I don't want to take this project over or at least not alone.

Whoever is responsible for the simutrans organisation on github, could you please set this up, so I can pass my repository of simutrans-extended to the simutrans organisation?

[Roboron]

I would send a private message to sdog. He seems to be the most active of the organization admins.

I'm only a member, so I cant' add you to the organization.

[Mariculous]

Done, thanks 

[prissi]

I think you strongly overestimate the degree of organisation. I have for instance no access to the github simutrans, only aburch has access. I can just commit to it via the svn ... Thus I think only James has access to the extended git. Only the owner can invite collaborators, but the collaborators \can only contribute. The infrastructure around it is a totally different matter, I think there are more people. For anything hosted here (on Isaac server), the webadmin user can do something about.

[Mariculous]

There is no need to access James repository.
As long as he's away, we can simply use a different one. That's the good thing about github (contrary to SVN, where it's possible but not that simple)

The idea of passing the repository to the simutrans organisation is simply to have an official place of the repository that does not depend on a single person.
I expected more than one person to have full access to the simutrans organisation on github though. If that's not true, there's indeed not a huge advantage compared to using a personal repository and permitting access to further people.

It's good to have all relevant simutrans projects in the simutrans organisation anyways.

Edit:The simutrans standard repository is not owned by the simutrans organisation. It's the personal repository of aburch. As it's just a mirror of the svn that's not a big issue anyways.
See https://github.com/orgs/simutrans/repositories

[prissi]

You can invite collaborators which can write and read. But to have more users review requests, one would need to set up an organisation account: on the team level that may cost money. https://github.com/organizations/plan (although is says at least for me $0)

It would certainly make sense to move the simutrans standard github there as well ...

[Mariculous]

Weirdly it shows $0 for me as well.
Anyways, most restrictions of the Free options do not apply to public repositories.
As we only maintain public ones, this shouldn't be an issue.

[Roboron]

There are more people with access. One of them is precisely jamespetts. Another one is aburch. But of course they don't use it, since their repositories are not on the organization, for whatever reason.

I agree that there are clear advantages for using the organization, and I've used it whenever I could. It's such a pity that we don't take advantage of it.

[Matthew]

Whoever is responsible for the simutrans organisation on github, could you please set this up, so I can pass my repository of simutrans-extended to the simutrans organisation?

Just a thought, but would it be better to re-fork James Petts's repositories using the Simutrans account? James Petts' repositories have been the official ones for Extended up to now, so that seems to be the cleanest way to make the change.

[Mariculous]

In the end it's just the same. The official repository will be a fork of James repository.
The cleanest way would be to transfer james repository to the simutrans account but we can't.

[sdog]

Is James alright?

He seemed active as usual just a month ago.

Fork or clone and push doesn't matter. Fork's just some github like hierarchy. In the end what counts is where forum and website point to.
James is also co-owner of Simutrans organisation. Main reason not to move it over to Simutrans on GitHub was that a lot of links would point to nowhere (or a stale repo).

We have currently 10 members in GitHub Simutrans. Five owners (Andz, Dwachs, Aburch, James, me). I will accept anyone I can match to devs or maintainers here on the forum. I will need to know your github account or an associated email. Just send in PM. Other owners may also add people.

Will elevate some immediately to owners. Might de-owner those who are inactive and don't care about it. Will also require 2FA in future.

I don't think we have limitations to our organization or costs as long as we keep it FOSS.

[Mariculous]

Is James alright?

Hello, gentlemen! As you know, it's been just over a week since Bridgewater-Brunel froze and we haven't had an update from James since then. The good news is that I have evidence that he is alive and well. The bad news is that if he is alive & well but not responding to messages about B-B, he may be on a lengthy hiatus.

We don't have much information as well. Maybe Mathew can tell a bit more.

[sdog]

There are more people with access. One of them is precisely jamespetts. Another one is aburch. But of course they don't use it, since their repositories are not on the organization, for whatever reason.

I agree that there are clear advantages for using the organization, and I've used it whenever I could. It's such a pity that we don't take advantage of it.

We discussed moving the repos to the organisation. However, we decided against as it would lead to umpteen dead links. Since actual development was not on Simutrans and aburch just mirrors it there wasn't all that much to be gained from team structures in any case.

[Roboron]

About "dead links", well, I remember the first time I tried to clone the svn source and it didn't found the URL the documentation pointed out (svn://tron.something). It's not the end of the world, you search for the new link and eventually old references will be updated. But I can understand not wanting to do it.

[Mariculous]

There shouldn't be dead links as the old URLs of the repository will redirect to the new repository.
It is recommended although not required to update links where possible to avoid confusion.

There now is a simutrans organisation repository of both, simutrans-extended and pak128.britain-ex

I have not yet checked who has access to these, and I'd like to setup a "no-push-to-master" rule, but in any case you should now be able to create pull requests agains that repository.
Any simutrans-ex dev is welcomed to use this repo at least until James returns.
When he does, it might be sensible to move his repository over, so that old links remain intact, whilst we still have control over the reposiory in case he disappears again.

[sdog]

I've sent and invite to Freddyhayward.

simutrans-extended and pak128.britain-ex require PR to merge to master.

I suppose we also need a pak128.britain-ex team. Who's innit?

[sdog]

There are still two elephants in that organization. pak128 and pak96comic are dead attempts to make SVN mirrors. We gave up about 7 years ago. Mostly because there was zero interest and difficulties we didn't find a way around*.

*Some .git files that were checked into the SVN that retroactively changed line endings.

[prissi]

pak128 is more recent on sourceforge. The mirror seems out of date. I can check it one can have a hook to push the svn to github on commit. However, it still badlz needs a maintainer ...

[Mariculous]

I suppose we also need a pak128.britain-ex team. Who's innit?

As pak128.britain-ex is the quasi standard pak of simutrans-extended, developement is closely tied to it.
Thus, practically most simutrans-ex contrubutors did also contribute to pak128.britain-ex.

[Matthew]

We don't have much information as well. Maybe Mathew can tell a bit more.

I have very little information other than the above and I don't want to source that out of respect for James' privacy. But he is choosing not to engage with Simutrans at the moment; I don't know for how long.

Everyone involved with Simutrans goes on hiatus from time to time and given that James has contributed so much of his time and money for so long, he's long overdue a sabbatical. In recent years, he's hardly played the game, so perhaps it just started to feel like work. He might be back tomorrow, but perhaps a long break will help him to return with fresh enthusiasm and ideas. His consistent commitment to open source solutions means that the Extended projects can continue.

[Dwachs]

Who of you is 'irgend42' on github?

[Mariculous]

Me

[prissi]

SInce SImutrans-experimental is already is a fork of aburch/simutrans and is in simutrans organization, standard cannot go there anymore, it seems. I get an error message, when trying to fork it. Either there has to be a Simutrans-Extended organisation, or standard has to stay as it is in the SVN, or someone with more git skills than me can create a fork of aburch/simutrans there.

[THLeaderH]

Splitting the simutrans organization into simutrans-standard organization and simutrans-extended organization would be the simplest way.
Since the contributors for these two repositories are quite different, splitting the organization makes sense.

The theoretical best way would be duplicating the repository for simutrans-extended. I think simutrans-extended does not have to be a fork of aburch/simutrans anymore, thus duplicating jamespetts/simutrans-extended in the procedure of this guide would make sense.
https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository

[Mariculous]

SInce SImutrans-experimental is already is a fork of aburch/simutrans and is in simutrans organization, standard cannot go there anymore, it seems.

Oh yes, that's a github restriction I really forgot about :(

As there are not yet many links to simutrans/simutrans-extended, I agree with THLeaderH that it's a good idea to split the company into two companies now.
This will also fix the same issue on all paksets joining the organisation, except from those maintaining both versions in the same repository (pak192.comic)

Any opinions on this?

[prissi]

It strongly oppose creating something named "Simutrans-Standard", this naming convention was invented by experimental. Experimental is still based on vanilla Simutrans like OTR. Therefore, I think the repo should be rather Simutrans/simutrans for the origin.

Maybe it can be after the cloning and adding of simutrans/simutrans-experimetnal it can be added back on the command line as upstream?

Unfortunately team has become now $4 while it was free two months ago ...

[Mariculous]

It strongly oppose creating something named "Simutrans-Standard"

Sorry, that was a typo.
I meant to move simutrans/simutrans-extended to simutrans-extended/simutrans-extended, so simutrans (standard) can join the simutrans organisation.

I have set up a testing organisation: https://github.com/simutrans-test
Seems like a fork of aburch/simutrans and an unlinked simutrans-extended can co-exist.
As forks are not a git thing, but a github specific concept, you can surely still interact with any simutrans standard or extended repository on the git level. That means pull, merge, cherry-pick and stuff like that will still work, but the "this branch is ... commits behind master" status nor pull requests between them wil work.

If unlinking extended from standard is considered the way to go, we need James to agree with this, so he can ask the support to unlink his repository from standard.

[prissi]

I would certainly like to hear his comments, as his workflow depends much more on github. In priciple, I could import also the svn into a new git repo and push that to github, if wanted, but then again one would loose the connection.

[THLeaderH]

Freahk, thank you for setting up the test organization. I like Freahk's approach which unlinks simutrans-extended from aburch/simutrans hierarchy.

[Roboron]

I also like more the approach of removing the fork status of Simutrans-Extended. Not only because I don't like the idea of splitting organizations, but also because it would also simplify things for me. Currently, I can't maintain a personal fork of Extended and Standard at the same time, I have to delete one of them first. That piss me off when submitting/testing changes for both Simutrans.

[Andarix]

I would appreciate it if there would be releases of Simutrans-Extended again. Releases can be better used and tested by a wider base of gamers.

[Mariculous]

I agree with the general idea of releases, but I am not sure how this can work in extended at the moment.
The issue is the lack of testers and feedback (bugreports). Besides Ranran and very few further, all of the bugs reported have been observed on the bridgewater server.
I am not sure how useful releases are whose bugs are not reported.

[Andarix]

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.

[Mariculous]

Yes, that's all correct, but introducing releases without ensuring that these are notably more stable than the nightlies and existing bugs get fixed seems pointless to me.
So how can this be ensured?

[prissi]

Do not put a major feature in and wait a monht. If nothing really bad comes up, make a release. However, a release needs usually a little more work (no DEBUG compile, check the translations, find the corresponding pak set(s) etc.) installer and so on.

[Mariculous]

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

[Mariculous]

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.

[Mariculous]

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.

[Mariculous]

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?

[Mariculous]

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.

[Mariculous]

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.
 

[Mariculous]

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.

[Mariculous]

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?

[Mariculous]

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.

[Mariculous]

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.

[Mariculous]

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

[Ranran(retired)]

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.

[Mariculous]

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.

[Yona-TYT]

It is necessary to update the GitHub link on the simutrans page so that it points to the new repo within the organization.

[Roboron]

It is necessary to update the GitHub link on the simutrans page

Link updated. Also removed the link to svnlogs as that site no longer works.

[Yona-TYT]

Link updated. Also removed the link to svnlogs as that site no longer works.

Recently I have also learned some web backend, maybe I can help solve those details in the future.