Topic: Moving to sf.net and preparing a release

[VS]

Hello,
in the next few days an alpha version of open-sourced pak128 will appear. Right now, a lot of things are somewhat broken since we're "moving house". I'll try to summarize what happens behind the scenes.

The old svn repository for pak128 was hosted first by Werner and then Timothy. Right now, it is still reachable on Timothy's server. However, it is non-public, svn-locked, and write-protected. This means that existing team members can still view full history.

New svn location is at sourceforge, along pak64, pak128.Britain etc. The folder name is pak128. Currently not even 20% stuff has been imported, but watch that space Naturally, all unlicensed material will not be added there.

Release will happen once the svn content produces a working pak128. It will be an alpha, since there are still numerous problems and some bugs. Don't expect a great experience yet It will be also identical to last nightlies, nothing ground-breaking there.

Translating pak128 is temporarily disabled. Working with STL as a developer is clumsy and as a result, it was severely outdated after the numerous changes made during last months. A few hundred objects were deleted and about as much added. The whole set definition and all translations will be deleted and re-imported. Existing translations are fully preserved. Once everything is right, you will be able to translate again.

And that's probably all... ETA 2 days for svn move, maybe a release before Easter. Translator will take longer.

[Zeno]

Before Easter would be really quick. Meanwhile... awaiting orders, sir!

[Václav]

Splendid new that pak128 is going to be found on sourceforge.net too - along to pak128.britain and some other paksets.

[VS]

SVN move is finished, and produces a near-identical pakset except for a few minor bits that were improved in the process. It has not been tested thoroughly, though...

New svn location: https://simutrans.svn.sourceforge.net/svnroot/simutrans/pak128

Anonymous access allowed of course For team members, register on sf.net, then ask project admins (listed here) to add you as contributors.

[Václav]

For this time I would like to know: is translation ready again or not?
I hope that there is better synchronisation between translator and new svn - because in Czech language (and may be in some other ones) new electronics factory (and may be some other) has been untranslated for very long time - because it was not in list.

For this time I let somebody else to decide if any my add-on will become part of set - but I have following condition: before each adding of new my object will be poll - or three months of using.

[sdog]

I'm just looking  into doing a git mirror on github. To sync continously it needs a server, github doesn't provide this at the moment.

right now i try to fetch it from the svn and update my old snapshot of pak128, in my local git repo. if this works i'll be probably half way to at least a semi static git hub mirror.

The other obstacle is creating a authors list, mapping the authors in the git repo to git authors. Doing this properly might take more than a moment. If i can't do it to-night i will likely have to postpone it for quite a while.


edit: always hoped i could avoid geting exposed to svn, which i only heard the worst off.

[VS]

Considering that we can't exactly branch pictures, you should be shielded from most of the svn deficiences... I hope

[prissi]

Why? Imho GIT is much worse as svn for a packset; especially for storing binary stuff, since it saves a snapshot of every version compressed (which does not mean much with images). Thus the GIT of pak128 will be large in the client (while the SVN of a pakset is only large on the server).

Subversion is much more portable; git is very much tailored for Linux and does not work on most other platforms, (apart from being very bloated). But if you use a graphic interface, the use of which version management system does actually not matter.

[Frank]

...
Translating pak128 is temporarily disabled. Working with STL as a developer is clumsy and as a result, it was severely outdated after the numerous changes made during last months. A few hundred objects were deleted and about as much added. The whole set definition and all translations will be deleted and re-imported. Existing translations are fully preserved. Once everything is right, you will be able to translate again.
...

I think it better create a new object set for openpak128

removing object set pak128 later

[Zeno]

I think it better create a new object set for openpak128
removing object set pak128 later

The idea is to allow migration between already translated objects in pak128 standard and openpak128. Would that migration be possible by creating a new object set?

[VS]

Zeno: Yes, because you could export one and import to the other.

Frank: Why is this better? You are the expert, so I'll follow your advice, but I don't know if we understand. The "open" is not pakset name, just type of release; this will not be a second pakset. But there are many (hundreds) deleted objects and I can delete in ST only by one. For me, it will be faster to delete & upload objects and re-import texts. Is there any technical reason to not do that?

[Frank]

Now is always quickly extinguished

The other is that the sets in the translator are now grouped according to size or theme graphic (comic). pak128 but for historical reasons mentioned in the '64 set is.

I can rename the exists pak128 to pak128-outdated and create a new pak128.

Changing the set-ID in the database is not currently possible. It would mean a lot of effort to make.

Also delete the entire set is not possible. So also set entry in the selection fields.

[sdog]

Why? Imho GIT is much worse as svn for a packset; especially for storing binary stuff, since it saves a snapshot of every version compressed (which does not mean much with images). Thus the GIT of pak128 will be large in the client (while the SVN of a pakset is only large on the server).

i don't care how much space it takes, i don't have to pay for the space at github. the pakset is tiny anyways. even with plenty of branches it's unlikely to blow up beyond a few GB.

github allows people to create forks much more easily. this encourages people to do so. file access and editing is easily available online. git itself is quite powerful, with a quite userfriendly interface. it seems to work reasonably well in windows too, since james is using it.

last but not least, integrating colaborative work is very straightforward in git, eg no bothering about copying binary files.

prissi, i can't see any reason not to mirror the svn on github.

Subversion is much more portable; git is very much tailored for Linux and does not work on most other platforms, (apart from being very bloated). But if you use a graphic interface, the use of which version management system does actually not matter.

svn isn't taylored to *nix? The graphics interface would be github. I have no experience with sourceforge, but it seems to provide a good gui for you.

[VS]

Let's keep this on topic, please? Not another git vs the rest of world thread.


In other news, I finally managed to beat sf.net and release the alpha version. Strangely, bicycling to school with flash disk still gives higher bandwidth than DSL.

I will work on translator next week, for now translating is locked.

Converting removed items into addons... still later.

[prissi]

You can purge a pak set; the translations will remain. Upon uploading the new object, only existing objects will get a translation. No need for one by one deletion.

[sdog]

as promised an aeon before, i began to mirror the svn to git:
git@github.com:sdog/simutrans-pak128.git outdated!
git://github.com/pak128svn/simutrans-pak128.git new link

the cronjob checking the svn for updates is set to every half hour. To actually see if it's working as intended i have to wait for changes in the svn though. I'll come back to this topic.

For contributers using the git mirror, the way to get something included into the pak would still be creating patches and providing the maintainers with those.

ps.: the mirror is tiny, only 230 MB

[VS]

230 MB is tiny? Well, that's just the initial commit, you don't have history of changing images

And you just got a commit to test with

[sdog]

it's there!

ah, now i see, there's only commit history since april. I haven't checked before. So you did not transport the commit history from the old svn?

I suppose like other cloud applications github can save a lot of disk space by having multiple users having the same files. Since lot of things branch from each other, it might be even easier for them. There's a soft limit for my space on github at 300 MB, if there are branches or downloads from this repository it's likely we can easily get more space.

i've just realised it would be more useful if i run this repository on a seperate account specific for this purpose. (which can also more easily passed to someone else should the need arrise.

[VS]

The recorded (versioned) history is largely a story of phasing out graphics without copyleft permission, so it has been left out on purpose. The original repo is still up, protected, backed up and locked, allowing introspection in case it's ever needed. I think about three people also have a dump of that...

[sdog]

the new link to the git repository is:
https://github.com/pak128svn/simutrans-pak128

git://github.com/pak128svn/simutrans-pak128.git


@VS i'll send you an email with the login and password, if you want you can add an email address of your choice for password recovery purposes.

it makes sense not to have the whole commit history, especially if it is non-free. I just wasn't thinking of that when i saw a long list of commits. BTW, on github it's only 100 MB. (That's also explains why i was a bit surprised that it uploaded without any noticeable delay, i wondered about that yesterday.)

[gwalch]

I would like to know when translations for "new" pak128 will be enabled ?