Bugzilla – Bug 902
SVN filesystem reorganization
Last modified: 2013-01-21 13:26:27 UTC
Currently, our subversion filesystem is kind of a mess. To clean it up, I propose we move stuff around to something a little bit more ordered.
To start, let's put the entire Odamex source tree under /source.
trunk/common/ -> trunk/source
trunk/client/src -> trunk/source/client
trunk/server/src -> trunk/source/server
trunk/client/sdl -> trunk/source/sdl
trunk/server/win32 -> trunk/source/win32
trunk/textscreen -> trunk/source/textscreen
trunk/Wii -> trunk/source/wii
trunk/Xbox -> trunk/source/xbox
Second, let's talk about libraries. HyperEye suggested keeping a .zip of every library needed to compile Odamex on odamex.net, moving it out of SVN. It does not appear that there is much of a desire to move more stuff into SVN, so this is a reasonable consistent alternative. However, there is the question of what ought to happen to libraries that are actually compiled into Odamex itself as opposed to simply linked against, such as PortMIDI. I think that smaller compiled-in dependencies like libminiupnpc and jsoncpp could remain in-tree under trunk/lib/, but PortMIDI...honestly I'm not so sure what to do about that since it's only compiled-in if you use the Code::Blocks project (on windows only?).
As far as everything else goes, I'm not sure. Perhaps trunk/media should be renamed to trunk/odamex.wad (a directory) so to be less ambiguous, but beyond that I'm not really sure what should happen to things like odalpapi. ag-odalaunch and
Last comment got cut off. odalaunch, ag-odalaunch and other 'subprojects' that are made by us should probably stay where they are at the root of the tree.
In addition to SVN reorganization, recent talks of moving to Github have sprung up in #odamex
+1 for the move to git. I personally use a git-svn bridge for development anyway.
This bug isn't for deciding a new VCS. Regardless of which vcs we use there will still be the same issue of reorganizing, so let's keep this bug to that topic specifically.