Cleaning up VDrift source tree

[NaN]

I'd like to move tools/win and tools/osx into separate repositories vdrift-win and vdrift-osx and get rid of the tools. Any objections? Is anyone requiring the other tools files?

[joevenzon]

The G25manage tool is useful. I like having the modelconvert available also, although I'm fine with them being in a different repo if you want.

[NaN]

@joevenzon:
OK. Can you move vdrift art repo to vdrift.sourceforge to have all data in one place?

[NaN]

I think we can also drop/remove the code.google project, use github instead.

[joevenzon]

I've made a comment in the google code project indicating it's going away. I will delete it after that's been up there for a bit. Should I migrate some (?) issues from the google code site to github? It's probably a good opportunity to take another look at what's in there....

I moved the art repository to:
https://vdrift.svn.sourceforge.net/svnro...-art/trunk

I made the old art repository private so only people who previously had write access are able to see it. I'm going to leave the repo like that in case anyone needs to look at history.

[BiGBeN87]

Let's keep data on sourceforge. DVCSs aren't that useful for binary files.

Do you have any data to back up this statement? I do not see how DVCS are conceptional less useful for binary files. To my knowledge SVN specifically does not handle binary files any better than Git does. See: http://stackoverflow.com/questions/11262...23#1126323

On the contrary I am of the opinion that using Git as a DVCS for the data, too is very gainful. For example, splitting up the data into individual cars/tracks for more atomic development and pulling it back together with submodules is a feature that only arises from a distributed paradigm. See: https://github.com/VDrift/vdrift/issues/...nt-2188956

[alex25]

On the contrary I am of the opinion that using Git as a DVCS for the data, too is very gainful. For example, splitting up the data into individual cars/tracks for more atomic development and pulling it back together with submodules is a feature that only arises from a distributed paradigm. See: https://github.com/VDrift/vdrift/issues/...nt-2188956

is the fact that the data is in svn stopping you from contributing cars/tracks? if so maybe we should change it. in the mean time i prefer it the way it is. thanks.

--alex--

[BiGBeN87]

is the fact that the data is in svn stopping you from contributing cars/tracks?

It kind of does, actually. Perhaps not me as a person, who happens to be code affine, but the general type of person who happens to come along and wants pour in some skill. I might be able to checkout the SVN, make changes, create a diff and post it on this forum. The latter might find that too big of a hurdle and quite frankly an obscure process.

If VDrift Data was on GitHub, one could fork with a single click, edit files online, create and discuss a pull request all in one integrated web site. I think, having the VDrift Data on GitHub would lower the barrier for small contributions without rising it for bigger ones, since you can still clone the repository/ies and use IDEs/3D-Editors and so on.

In effect, I think, having the VDrift Data on GitHub would be very opportune, because it facilitates contributions, which is part of the projects goals:

The goals of the VDrift project are:
[…]
- to provide a platform for creative experimentation to a community of developers and artists.

[alex25]

If VDrift Data was on GitHub, one could fork with a single click, edit files online, create and discuss a pull request all in one integrated web site. I think, having the VDrift Data on GitHub would lower the barrier for small contributions without rising it for bigger ones, since you can still clone the repository/ies and use IDEs/3D-Editors and so on.

you are a troll. make a contribution first and then start spouting nonsense (if you still feel like it).

--alex--

[BiGBeN87]

you are a troll.

You must have misunderstood me. I am interested in the result of this discussion, not in this discussion itself. I also would prefer spending my time contributing than arguing. I really believe that the VDrift Data should be hosted at GitHub and therefore not a troll.

So right back at ya. You are the one picking up on my critique, which I originally addressed on joevenzon. You are the one bringing up an argumentum ad hominem twice. You are the one deterring me from contributing. You are trolling me.

make a contribution first and then start spouting nonsense (if you still feel like it).

There is my contribution: https://github.com/VDrift/vdrift/pull/49...ft/pull/49 which I would probably not have done, if VDrift weren't hosted on GitHub.

Interesting tenor of an open source project though. You think, who has made a contribution may spout nonsense and who hasn't is called a troll even if he is making a reasonable argument? Maybe I do not want to contribute to that, after all.

[alex25]

first you walk the walk, then you talk the talk... maybe you can come up with a readme for the data as well. make your request here when you're done and i'll make sure it gets pulled.

--alex--

[BiGBeN87]

https://gist.github.com/1246490 - Not much to say about the data directory, it seems. Are there other places with documentation on this than the wiki and this forum?

[antoniovazquez]

I also prefer data on GitHub...

Can anyone create vdrif-linux github repo for starting with ubuntu deployment? Thanks.

[BiGBeN87]

vdrif-linux github repo for starting with ubuntu deployment

I don't see too much value in that. On Windows and Mac OS there are libraries needed at compile time and therefore is makes the repository lighter to exclude them. On Linux on the other hand usually all libraries can be installed via package management.

One could source out the scons-script, since it is only usable under Linux and Mac OS, but since it is only 20 KB in file size that is not too big of an issue either. Ubuntu Linux specific instructions on installing are incorporated in my upcoming readme, already: https://github.com/bigben87/vdrift/blob/.../README.md

I think the general direction should be to streamline the installation process on all platforms and make them more blend into each other. Minimal readmes should than be kept in the platform specific repos and one comprehensive readme in the main repo. More detailed Information should be kept in the wiki, and linked, where appropriate, i think.

[antoniovazquez]

Ok BiGBeN87. You're right. I was thinking the other way but your option is very reasonable.