search

koraktor / steam-condenser

A multi-language library for querying the Steam Community, Source, GoldSrc servers and Steam master servers
https://koraktor.de/steam-condenser
Other
359 stars 65 forks source link

Put different languages into their own repos #119

Closed timmw closed 12 years ago

timmw commented 13 years ago

Is there any chance that each implementation be put into its own repo? It would make it much easier to pull updates to our own projects I understand that you want to keep the implementations the same as each other, maybe that's why you've chosen to put them all in the same repo.

txdv commented 13 years ago

csharp is in its own repo :D

koraktor commented 13 years ago

I already thought about that in issue #77.

I'm really not sure at the moment. Generally I think it's a good idea and it's technically possible. There could be other repositories for each implementation included as submodules in this repository. But I'd really like to have the wiki and the issue tracker in a common place (i.e. here). Maybe I just ask GitHub support if it is possible to redirect those buttons (and not just disable them). If it works, I may really start thinking about it. :)

klaussilveira commented 12 years ago

Why not git submodules? I believe their behavior is more than perfect for this task. Also, it would be easy to integrate each build with a proper continuous integration job, either with Travis or maybe a custom-made Jenkins setup.

http://progit.org/book/ch6-6.html

gutomaia commented 12 years ago

I agree with @klaussilveira. In fact, we have this conversation at lunch today. Also it will be easy for some developers to follow what is really going on. Like, PHPDevelopers could follow just the PHP submodule, the same for JAVA and what ever flavor do you intent to build.

katanacrimson commented 12 years ago

@koraktor considered using a master repo with a subtree split, and have each language in its own repo/submodule? Could also do it as a github organization as well.

Though in all honesty, having issues for all the submodules together under one repo is less than ideal - most often you'll have an issue just affecting one repository - if it affects multiple repos, you can just create an issue for each and mention the related issue in the other repo in the issue description - github's issues tracker automatically does a traceback on the original issue when mentioned. For example: https://github.com/koto/phar-util/pull/14#issue-ref-5072644

klaussilveira commented 12 years ago

Steam Condenser can be one big repo, holding the Wiki, Major Issues, Documentation and other information about the project as a whole. This big repo would include three submodules, PHP, Java and Ruby. These three submodules are normal GitHub repositories, with their own issues and wiki.

Having everything in one repo is a problem... right now i don't know where to put the .travis.yml for the PHP build. :(

Holek commented 12 years ago

how about using branches for each language, like "ruby", "php" etc.? That would also solve problems with multiplatform Travis CI integration, because each branch would have its own .travis.yml with tis own settings specific for that language.

And on top of that you retain the issue tracker, wiki and everything else in just one repo

klaussilveira commented 12 years ago

I don't think that branches should be used for holding completely different codebases... not only it's easier to mess things up, it's pretty confusing.

Anyway, do you guys agree that having issues, wiki and other features in one repo is a good or bad thing? In my opinion, it's bad... issues and other information should be related to the specific language codebase. Examples, API, issues for PHP should be tracked with PHP only.

gutomaia commented 12 years ago

I don't like it. That would generate even more problems when we try to deal with feature branches. And also will not be obvious for newcomers, like me!

Guto Maia @gutomaia

2011/11/22 Mike Połtyn < reply@reply.github.com

how about using branches for each language, like "ruby", "php" etc.? That would also solve problems with multiplatform Travis CI integration, because each branch would have its own .travis.yml with tis own settings specific for that language.

Reply to this email directly or view it on GitHub: https://github.com/koraktor/steam-condenser/issues/119#issuecomment-2841591

katanacrimson commented 12 years ago

@gutomaia not just newcomers, but anyone used to how git is normally used.

Independent codebases belong in their own repositories, not in separate branches. Branches are for codebase variations, tags are for specific releases, and repositories are for codebases.

koraktor commented 12 years ago

Just a quick update on this one: The repository will be split in the not so far future, using a submodule for each implementation and a main repository that includes them and holds at least some basic information like a global README.

Branches would technically be fine too, but are problematic to handle. Additionally, you have to choose a default branch. Although I do prefer Ruby, I don't want to impose that choice to anyone.

Regarding issues I'd really prefer a single contact point. The basic implementations for each language are equivalent and thus share the same flaws (hopefully not that much any more). This is obvious throughout the whole development of Steam Condenser. That said, I don't see a reason to split issues too. I'm open to other opinions, but I think it would inherently complicate handling of issues for users and developers alike.

klaussilveira commented 12 years ago

Well, enable the issues and wiki module on the main repository and disable those modules in the submodules. The admin page of each repository allows you to do so.

katanacrimson commented 12 years ago

@koraktor in case you've not seen it, this'll be how to do it (I recently found it myself and needed it, figured it'd help to link): http://help.github.com/split-a-subpath-into-a-new-repo/

gutomaia commented 12 years ago

@koraktor I've done some script tests with github, and I was able to clean up a repository with only commits related to Java and Ruby.

Course in order to do that. I've have to erase everything related to something, and erasy empty commits.

I belive that this issue could be fixed sonner in order to use travis continuos integration for php project, and jenkins more out-of-the-box for java.

gutomaia commented 12 years ago

Look on my user. There is a specific java-project and a specific ruby-project.

koraktor commented 12 years ago

Thanks, but I would recommend you to not put more time into this. I will split the repositories soon and I'll probably make more changes than just the split itself (as I'm rewriting the history anyway).

Stay tuned.

koraktor commented 12 years ago

Ok, I started new repositories at:

All three contain the whole history of one implementation (done using git filter-branch). All old tags are still in place, although they are not signed. I decided to not tag and sign again, because the real tags remain in the old global repository. To mark the start of the "split" development I created a lightweight tag called repo-split in all four repositories. Finally, I added the three implementation repositories as Git submodules into the global repo, currently in branch repo-split.

koraktor commented 12 years ago

The split is now also active in the master branch and the 1.1.0 release just used the submodules.