Difference between revisions of "Version Control"
Jump to navigation
Jump to search
no edit summary
imported>HaploTR |
imported>HaploTR |
||
| Line 111: | Line 111: | ||
== 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 | As mentioned at the top of the page, this document will not explain how to use external revision control software such as Perforce or 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). | 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). | ||
| Line 120: | Line 120: | ||
** 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. | ** 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. | ** 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 | * Even when properly merging changes one after another - using the last person's updated .esm to initiate your next merge - it's important that team members aren't working on the same assets, thus simply overriding the previous person's change. | ||
** As an example: | |||
*** Let's say that two people decided to move already existing architecture assets in Layer_7 | |||
*** User one moves a room down because they want to add an elevator, and they save these changes to their .esp | |||
*** User two moves the room backwards because they want to add a hallway that leads to the room, and they save these changes to their .esp | |||
*** User one correctly communicates his intent to merge into the .esm | |||
**** User one downloads the latest version of the .esm from the online repository, and initiates the merge process in the Creation Kit | |||
**** User one uploads the new .esm to the online repository | |||
*** User two correctly waits for user one to finish | |||
**** User two downloads the latest .esm that user one just finished uploading, and initiates the merge process in the Creation Kit | |||
**** User two uploads the new .esm to the online repository | |||
** Uh oh! User two, though following the correct queue for merging changes, just blew away user one's changes. It's as if the room was never moved down, but the new elevator to nowhere probably looks great. | |||
This may seem like an obvious example of where merging can go wrong, but there are many different types of content, assets, scripts, etc... that may be less obvious. Always keep this in mind, and promote frequent communication on your team. | |||