Forums

Full Version: Cleaning up VDrift source tree
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Before we do another release, and move the source code to github, we should clean up any unused stuff. Moving time is always a great time to throw out old unwanted junk. Smile

Here's a list of things that haven't been touched in the source tree for a long time, and probably aren't used or aren't necessary any longer:
  • binaries/ - 19 months old - only contains a very old linux 32-bit binary
  • docs/ - 2 years old - this is sort of a separate topic, but this should probably just be replaced with a README.txt file that tells users to visit the wiki for now, until we get some way to generate full (current!) docs from the wiki, or something like that.
  • po/ - 2 years old - we are using a new type of internationalization now, this is no longer needed, the SCons build support has been removed.
  • VDrift.kdevelop* - 19+ months - Joe has stated he no longer uses KDevelop, so these are no longer being maintained.
  • gpl.txt - change to LICENSE.txt?
  • Doxyfile - should go in tools/?
  • grind - should go in tools/?
  • tools/anjuta/ - 2 years old - same as kdevelop stuff
  • tools/autopackage/ - 2 years old - not going to use this anymore, Autopackage is defunct
  • tools/cars/ - 2 years old - this contains an empty .car file which is really old and probably wrong. it would be better to have in the VDrift-art tools/ dir, or better yet, to write a generator script that uses a file like this as a template to create a blank car with some values filled in.
  • tools/debian/ - 2 years old - this is old, however could be updated with some information someone posted here: http://wiki.vdrift.net/Talk:Compiling#Bu...B_packages
There are probably other things to clean up, but those are most obviously old and unused.

Please post how you feel about these changes. If you feel something in the list needs to stay where it is, please include a simple explanation why.
All OK to me.
@thelusiv:
Any progress? I could move the repo to github if you're short on time. My user name is logzero.
NaN Wrote:@thelusiv:
Any progress? I could move the repo to github if you're short on time. My user name is logzero.

YEEES GITHUB! That would make things easier. If anyone of you create an account for this project I can help uploading code and data to github as it is very very big.

Is it a good idea to move LICENSE.txt to docs folder?

Thanks!
NaN Wrote:@thelusiv:
Any progress? I could move the repo to github if you're short on time. My user name is logzero.
Done! Sorry it took so freakin' long.
thelusiv Wrote:
NaN Wrote:@thelusiv:
Any progress? I could move the repo to github if you're short on time. My user name is logzero.
Done! Sorry it took so freakin' long.

Forked!
So, are we officially on Git now? Should I turn off the SVN code repo?
I don't know if I'm forking the right repo in github. Can anybody link the repo here? Thanks.
Well all I can find is thelusiv's repo; https://github.com/fjwhittle/vdrift which is out of date and https://github.com/VDrift/vdrift with only a readme in.
Yeah, I guess I jumped the gun; thelusiv meant he granted NaN access, not that he transitioned the repo.
I've imported trunk from rev 2504(2009 release) + driver-training branch using svn2git: https://github.com/VDrift/vdrift

To be able to compile you'll need bullet-devel.

TODO: Import Art, Pacejka Editor, Track Editor repos. I think data can stay on sourceforge?
NaN Wrote:I've imported trunk from rev 2504(2009 release) + driver-training branch using svn2git: https://github.com/VDrift/vdrift

To be able to compile you'll need bullet-devel.

TODO: Import Art, Pacejka Editor, Track Editor repos. I think data can stay on sourceforge?

Can we clone bullet from their repo? It would be nice to have data in github but i understand it is very big...
You can use latest bulllet
Code:
svn checkout http://bullet.googlecode.com/svn/trunk/
Put it into vdrift/bullet and run:
Code:
scons extbullet=0
NaN Wrote:I think data can stay on sourceforge?

I think that if possible we should have everything in the same place.
Let's keep data on sourceforge. DVCSs aren't that useful for binary files.
Pages: 1 2 3