Difference between revisions of "Version Control"
no edit summary
imported>HaploTR |
imported>HaploTR |
||
| Line 110: | Line 110: | ||
== Workflow for multiple team members contributing to the same .ESM file == | == Workflow for multiple team members contributing to the same .ESM file == | ||
As mentioned at the top of the page, this document will not explain how to use external revision control software such as Perforce of Git, but now we will discuss the workflow for multiple team members contributing to the same project while using such software. | |||
Now that your .esm is created, you'll want to upload it to your depot/repository (whichever terminology applies to your software - we'll say "repository" going forward). | |||
There are a few things to remember with multiple team members working on the same master file. | |||
* Merges into the .esm by different people must be done one a time. | |||
** If two people were to make local edits to the mod, and then merge into their local .esm at the same time, work will be lost when both people go and upload the latest master file to the repository. | |||
** Revision control software usually has their own tools to merge files like this together, but depending on what the changes are (especially changes to new custom content) that can be difficult, and is sometimes just not possible when two people's changes collide. | |||
** Luckily the backup directories we created way at the top of this page are used by the Creation Kit to backup your .esp file. If a team member was to merge into a local .esm out of turn, their .esp is still in tact in the backup folder, and they can step back in line to merge in the proper queue. | |||
* Even when properly merging changes one after the other, using the last person's updated .esm to initiate the next merge - it's important that team members aren't working on the same assets, thus simply overriding the previous person's change. | |||