Using version contro system

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Using version contro system

      I have a question regarding version control systems. Is it a correct that when developing a game application that there are two main lines (trunks) - one for the engine and one for game? Would it make sense to subdivide the engine into several trunks for each subsystem (AI, Collision Detection, Animation, ...) or would you branch the subsystems fro the trunk and then merge them back into the main branch when they work?

      -Dirk

    • RE: Using version contro system

      Are you asking about a directory structure or separate code branches like you can do in Perforce?

      A good directory structure is important for organizing code - and I've seen some REALLY bad ones.

      Branches in the code base are important for different types of development - i.e. main line development and milestone acceptance.

      Which are you asking about?
      Mr.Mike
      Author, Programmer, Brewer, Patriot

    • I am asking about code branches. The directory structure I use is perfect and works fine - its yours from the book :) When I develop an engine will it make sense to have the main trunk representing the whole engine and then branch the seperate systems (rendering, physics, etc) from it. When everything works fine it can be merged together to the final system.

      Isn't the milestone acceptance meant for the game trunk. I remember that you said that there are two sperate trunks - one for the engine and one for the game?

    • Ah - gotcha.

      When you branch a code line, you send it into a "different" philosophy of development. You generally branch everything, but you don't always remerge with the main line. Let me give you a few examples:

      1. You want to send a complete build to QA for serious testing - you branch everything. That branch will recieve only those changes needed for QA to test that branch (anything like horrible crashes, playtest blockers, etc.). Everything done in that branch eventually gets merged back into the main line.
      2. You want to test some serious new technology - like a new rendering engine - branch everything and swap your old crappy technology for the spiffy new stuff. If it works out, you remerge with the main line. If everything breaks or the new renderer really sucks, you DONT remerge with the main line.
      3. You are finishing a product - you branch sometime between code complete and content complete (it's hard to say exactly when) and you may or may not merge individual changes with the main line, but probably not the aggregate of all changes. Changes that happen at the very end of a project tend to be pretty crazy.

      In other words - you branch entire functional units as a whole, depending on what you want to do with them. You'll rarely branch just your renderer or sound system - perhaps only to perform some experiment.

      Does that help?
      Mr.Mike
      Author, Programmer, Brewer, Patriot