Spring RTS Engine

Does the CLI let you easily decide which of the 1,000 modified files you currently have in working dir should go into the next commit? That's the big thing I'm concerned about.

@topic: SpringPy also needs moving to github, but I'm way too lazy atm. I'll probably put it off till the second or third deadline

Someone needs to travell over there and inject some speedy gonzales again, do we? Move your lazy lizzard ass

KingRaptor wrote:Does the CLI let you easily decide which of the 1,000 modified files you currently have in working dir should go into the next commit? That's the big thing I'm concerned about.

Yes, you add files with "git add path1 path2...". What's more awesome, you can decide which parts of a single file you want added with git add -p (really easy to use).

from rapid-sync these repos are still on google-code:

http://springbrickcraft.googlecode.com
http://conflictterra.googlecode.com
http://frontier-spring.googlecode.com
http://micronwars-2.googlecode.com
http://spring-features.googlecode.com
http://springtanks.googlecode.com
http://xta-springrts.googlecode.com

how to handle these? ideally the project owners move them to github (or sth. similar). who pokes the project owners?

who watches the dutchman?
Or will those projects go down with google code? We should raise the union jack and sing the anthem?
Everything goes to bits in the longest run- vannishing into the night..

I"m moving spring features as we speak.

Google code has an "Export to github" button now.

We in xta are discussing this issue, it's not like there's a hurry, August 24 is the deadline afaics.

Clone abandoned projects with inactive authors and put them on Github. Rest will probably be moved somewhere eventually.
Stuff that needs cloning:
http://conflictterra.googlecode.com
http://frontier-spring.googlecode.com
http://micronwars-2.googlecode.com
https://code.google.com/p/darius/

There are other inactive projects, but their authors are active.

We should clone them into spring/modname unless someone wants to maintain it.

I message snoop about CT.

It might make sense to have a separate github account, something like springrts-archive, to put those kind of projects in; to keep /spring for engine & infrastructure stuff.

Although, since it looks as though the majority of past Spring gamedev projects have preferred svn over git, it might make more sense to put them somewhere svn-able.

Silentwings wrote: it might make more sense to put them somewhere svn-able.

nonono! please not. i/we want to drop svn support in RapidTools/rapid. also a lot of projects already use git. having a few projects using svn makes stuff just more complicated.

I don't see BA dropping SVN though.. Maybe delay the killing of rapidtools/svn for now? :p

abma wrote:

Silentwings wrote: it might make more sense to put them somewhere svn-able.

nonono! please not. i/we want to drop svn support in RapidTools/rapid. also a lot of projects already use git. having a few projects using svn makes stuff just more complicated.

I didn't know that was the stance, maybe make an official announcement about this. The concerned gamedevs could be interested.

Jools wrote:I didn't know that was the stance, maybe make an official announcement about this. The concerned gamedevs could be interested.

this would require some deadline which i don't want (yet).

Github has an svn frontend. Git has an svn bridge.

It doesn't matter whether you svn in the safety of your home, but don't bring that out in public.

i/we want to drop svn support in RapidTools/rapid

First I ever heard of it. Idk if there is a good implementation reason for it, but it just seems harmful to me. Svn was used by the vast majority of Springs subprojects to date, and however many fans github might have, you also don't have to look hard (a simple google search will suffice) to find many people/projects that don't want it.

Svn was used by the vast majority of Springs subprojects to date

even spring used svn. but most project migrated to git because its better for many workflows as its a distributed revision control. so the closing of google code is a good point to migrate to git!

some reasons why svn + rapidtools is bad:
setting up svn rapid: https://github.com/spring/RapidTools/bl ... ts/test.sh

vs

setting up git rapid:

git clone ...
sudo script/to/change/apache/config

no additional step required for git, also svn mirroring is very error-prone, a lot of hacks have been added to make it run stable. svn update takes a lot of more cpu on server side when new commits are fetched/checked in comparison to git, also git is faster and uses less disk space.

code-wise libgit2 is a single library vs svn library are a bunch of libs( libapr1-dev libaprutil1-dev libsvn-dev).

this is why svn should die over time from the POV of RapidTools / server maintainance. only point against switching to git is that usage has to be learned first when svn is known, but there are A LOT of tutorials, howtos, i.e.: https://git.wiki.kernel.org/images-git/ ... tsheet.pdf

imo most people already know git, so why not switch/migrate to git?

The point is not "why not migrate to git", or singing whatever praises git might deserve - ofc github has much useful stuff and people will want it.

The point is that there are still many people/projects out there (as said, simple google search suffices) who don't want to use github, and could well be put off by it. If something is meant as a compulsory service for all Springs subprojects, its bound to do some harm if it intentionally doesn't support the widely used version control systems.

Silentwings wrote:The point is that there are still many people/projects out there (as said, simple google search suffices) who don't want to use github

i guess i don't understand. there are a lot of git hosters, no need to use github. i.e. https://bitbucket.org/PicassoCT/journeywar.git

its bound to do some harm if it intentionally doesn't support the widely used version control systems.

git is one of the most widely used version control systems. currently there are 14 git/rapid repos vs. 9 svn/rapid repos.

~40% SVN is hardly a small minority to be brushed aside