Going for a Merge

edited 2009 Jun 14 in Developers
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Blog.</i>

I think I need to merge the changes of the beta6 branch to the trunk before I can begin work on the unified networking. However, since there's fewer changes in the trunk, I thought it might be better to take the changes in the trunk post branch creation, merge them into the beta6 branch, giving us a new trunk. The old (current) trunk would be moved under the /branches.

I did first attempt a normal merge of the beta6 changes to the trunk, but basically every modified file ended up with conflicts, with some very odd results.

So doing the merge the other way around might turn out better. Any thoughts before I commence?

Comments

  • Looking at the diffs I'm thinking that it would probably be best if you switch the beta6 branch to the trunk and leave me to manually merge the changes (back) into the trunk later.
  • Sounds reasonable. I'll rename the current trunk and move it under /branches, and copy the 1.9.0-beta6 branch to /trunk.
  • Done. The bugfixing on the 1.9.0-beta6 branch can (and should) continue as before. I think I'll start a separate work-in-progress branch from the trunk now for my "phase one" changes.
  • I'll continue on with bug fixing in the 1.9.0-beta6 branch as I doubt there is anything I can do yet during the phase one changes(?).
  • That is probably the case.

    Here are the phase 1 goals (from the commit log message):
    <ul>
    <li> reorganize the engine sources into libdeng, libdeng2, server, and client subdirs
    <li> use CMake to build both Unix and Win32
    <li> functioning stub for the new engine Core in libdeng2
    <li> upon launch run dedicated server and client process
    <li> hardcoded to launch E1M1 of Doom1 (bypassing game setup and UIs for now)
    </ul>

    Phase 2 will then focus on setting up the connection between the client and server in more detail:
    <ul>
    <li>client process is aware of where the local server is located
    <li>client process starts singleplayer games on the local server
    </ul>

    The game should be playable when phase 2 begins so you can start to pitch in if you feel like it. The ultimate goal is naturally to improve the network game experience and make it identical to what the original single player games are like.

    So far my plan also has a phase 3, which starts focusing on revising the network communications using new libdeng2 code.
Sign In or Register to comment.