Bug Tracker – Bug 902

Source code file system reorganization

Last modified: 2019-08-12 21:51:46 UTC
Bug 902 - Source code file system reorganization
Summary: Source code file system reorganization
Status: NEW
Alias: None
Product: Odamex
Classification: Unclassified
Component: Server & Client (show other bugs)
Version: (old) 0.6.x
Hardware: All All
: P1 enhancement
Assignee: Odamex Bug Reporter
URL:
Depends on:
Blocks:
 
Reported: 2012-09-06 23:05 UTC by Alexander Mayfield
Modified: 2019-08-12 21:51 UTC (History)
1 user (show)

See Also:

Attachments

Add an attachment (proposed patch, testcase, etc.)

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 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
Comment 1 Alexander Mayfield 2012-09-06 23:05:49 UTC
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 UTC
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 UTC
+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 UTC
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 UTC
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 UTC
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 UTC
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.