You would probably benefit more from a form of version control. The method we use is rather simple. We have a subversion repository setup. The first thing imported was the untouched SDK code from the first release. From there, we branched it to a vanilla/ branch. We then do all of our changes on trunk/ (or for you CVSers, HEAD). On this latest release, we simply checked out the vanilla branch, and copied the changed files (well, the entire directory tree) into it. Then committed, and did an svn merge of the vanilla branch back on to trunk/
Well, hmm.. maybe that isn't so simple after all. but the benefits are worth it-- we now have a history of the changes to the vanilla SDK and a good way to merge changes onto our working copies. The only conflicts were the project files when merging from vanilla/ to trunk/ but thanks to Mr Meyers' list of changed files that turned out to be a trivial issue. On Thu, 23 Dec 2004 13:27:15 -0600, Jeffrey botman Broome <[EMAIL PROTECTED]> wrote: > Chris Adams wrote: > > Does anyone have any suggestions for putting these new changes into our > > own code? > > If you have the money to buy Araxis Merge, it does a REALLY good job of > helping you merge 2 (or 3) source code directory trees together. > > Beyond Compare also does a pretty good job of merging 2 source code > trees together. > > Simply extract the new SDK source code out to a temporary directory, and > run the merge between your code and the latest code, pick and choose the > things you want to merge in, and merge them. > > -- > Jeffrey "botman" Broome > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- Phil Bowens He who is the greatest of warriors overcomes and subdues himself. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
