Bug 902 – SVN filesystem reorganization

Bug 902 - (ARRAY(0x61af860)) SVN filesystem reorganization

(ARRAY(0x61af860))
Summary:	SVN filesystem reorganization

Status:	NEW

Product:	Odamex
Classification:	Unclassified
Component:	Server & Client
Version:	0.6.x
Hardware:	All All

Importance:	P1 enhancement

URL:

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)
CC List:	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 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.