Changes between Version 1 and Version 2 of Programming/Python/OrganizationOfBuildEnvironmentScripts


Ignore:
Timestamp:
Feb 19, 2016, 12:37:44 PM (9 years ago)
Author:
Vijay Varadan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Programming/Python/OrganizationOfBuildEnvironmentScripts

    v1 v2  
    22Jan 04 2016
    33
    4 I use [https://www.mercurial-scm.org/ mercurial] for version control. There are multiple repositories, typically 1 per game or product. If a game or product is complex enough, it will warrant multiple repos. The layout of the "sub-repos" within a project is fixed and the developer needs to ensure adherence to the layout to get the project to build. The need for multiple repos within a single project stems from having teams with different needs and schedules working on various pieces. E.g. artists and animators work on assets on a different schedule and publish content to their own repo. Developers, QA and automated build & test systems can use placeholder assets initially and subsequently integrate the final assets when they are ready. This also provides the flexibility of using a different version control system for art and sound assets which is better suited to binary files e.g. [https://www.perforce.com/ Perforce] rather than mercurial.
     4Consistent organization is important when building code that uses multiple external and internal libraries. It all starts with scripts that are used to setup the build environment. The scripts need to accommodate customization on per project, per role (developer, scripter, artist, etc), per user and perhaps ever per computer basis.
     5
     6I use [https://www.mercurial-scm.org/ mercurial] for version control. There are multiple repositories, typically 1 per game or product. If a game or product is complex enough, it will warrant multiple repos. The layout of the "sub-repos" within a project is fixed and the developer needs to ensure adherence to the layout to get the project to build. The need for multiple repos within a single project stems from having teams with different needs and schedules working on various pieces. E.g. artists and animators work on assets on a different schedule and publish content to their own repo. Developers, QA and automated build & test systems can use placeholder assets initially and subsequently integrate the final assets when they are ready. This also provides the flexibility of using a different version control system for art and sound assets which is better suited to binary files e.g. [https://www.perforce.com/ Perforce] rather than mercurial.
    57
    68Coming to the actual layout, it looks something like this on Linux and MSYS2: