What is the intended path to migrate from one build to the next?
Basically I’m trying to figure out the way to do it in the fewest steps. The last two versions I made a new project and pulled stuff over by hand, but that is going to grow more and more time consuming as the project gets bigger.
One of the most annoying part that I have is in the new VisualStudio project having to re-setup all the folders and virtual folders for organizing the source code. But, as there are more assets that will become an issue.
Is there a way to keep the same VS project when migrating to new build?
My second question is with version control. Last time, I made a new project, copied everything over to it, tested. Then I deleted everything on the Perforce server, the old build project, then added and uploaded the new project.
What is the correct way to setup a Perforce repo and the steps to migrate to a new build when it comes out?
For now with a tiny project that’s just prototyping is not that big a deal, but since the other guy on the project is in the Beta too, and just got the news about the licensing we are going to start production on it and I want to setup a process to follow that is sustainable for the next year or so and doesn’t drive us nuts everytime there is a new build.
With UDK projects, I only checked into source control the actual files that the project used, in a skeleton folder structure that could be checked out on top of any UDK install, compile and run.
I am not familiar enough with Rocket to know how to organize that.
Are there only a couple folders and some config files that need to get versioned as a minimum? That could get checkout on top of any new project that Rocket made?
I think that would be an easy process, if with each new build you just made a new blank project with the right name and then checked out your versioned files on top of it.