Bug Tracker – Bug 902

SVN filesystem reorganization

Last modified: 2016-11-19 17:02:25 CST
Bug 902 - (ARRAY(0x61af860)) SVN filesystem reorganization
(ARRAY(0x61af860))
SVN filesystem reorganization
Status: NEW
Product: Odamex
Classification: Unclassified
Component: Server & Client
0.6.x
All All
: P1 enhancement
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2012-09-06 23:05:03 CDT by Alexander Mayfield
Modified: 2016-11-19 17:02 CST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Mayfield 2012-09-06 23:05:03 CDT
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
Comment 1 Alexander Mayfield 2012-09-06 23:05:49 CDT
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.
Comment 2 HeX_Vulture 2013-01-13 05:48:03 CST
In addition to SVN reorganization, recent talks of moving to Github have sprung up in #odamex
Comment 3 Alexander Mayfield 2013-01-19 20:14:45 CST
+1 for the move to git.  I personally use a git-svn bridge for development anyway.
Comment 4 Mike Lightner 2013-01-21 13:26:27 CST
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.
Comment 5 Alexander Mayfield 2013-08-06 22:49:52 CDT
Hi.  I'm back with another reorganization:

cmake/
docs/
  config-samples/
  manual/
  notes/
    requirements/
    tech/
    uml/
installer/
libs/
  agar/
  jsoncpp/
  libminiupnpc/
  portmidi/
  sdl/
  sdl_mixer/
  textscreen/
launchers/
  odalpapi/
  ag-odalaunch/
  odalaunch/
master/
media/
odamex/
  client/
  common/
  proxy/
  sdl/
  server/
  wii/
  win32/
  xbox/
tests/
tools/
  deutex/
  upversion/
wad/
Comment 6 Alexander Mayfield 2013-08-08 03:31:15 CDT
After some IRC discussion, it might be prudent to move some of the odamex subdirectories dealing with platform-specific code into a "platform" subdirectory.

odamex/
  client/
  common/
  proxy/
  platform/
    sdl/
    wii/
    win32/
    xbox/
  server/
Comment 7 Alexander Mayfield 2016-11-19 17:02:25 CST
Thinking back to this, I don't actually think we need a special directory for common code.  Just stick it in common /odamex/ directory.

Also, now that we're on git, moving things around is much easier to do - git has implicit rename tracking, so we won't lose our history.