-- [ Picked text/plain from multipart/alternative ] You should read a bit about revision control systems. You should be using one anyways. A good versioning system can make keeping track of these diffs and patch files much more manageable. (note that I didn't say "easy").
Most of them will let you pull patchs from branchs and apply them to other branchs. Simply keep one branch made of nothing but the unmodified SDK code. When valve puts out a new version of the SDK, copy that into this unmodified branch as a new version. Then later you can make a diff from your mod's own development branch, of everything you've changed from from the original unmodified SDK as part of your mod. In most VCS this is just one command. And finally you can merge that diff into a copy of the latest version of the unmodified SDK branch. You'll have tons of conflicts to work out and testing to do, but its better than manually merging every single change. You can also use that unmodified SDK branch your keeping to make the official release diffs of your mod's source. Most VCS can generate and read unified diffs or several other common diff formats. On 2/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Agreed wholeheartedly. Thankfully I've archived every SDK update from > Valve, so when they introduce new features or bugs I'm able to track things > more easily. It would be a royal pain if I lost those..... > > At 2007/02/01 07:06 AM, Nick wrote: > >Yes, you are correct thats why I suggested there be some sort of way > >for valve to allow users to select which version of the codebase they > >wish to install. It would be much easier for all coders( open source > >coders, and closed source coders) if Valve allowed sdk users to > >download previous codebases. > > > >On 1/31/07, [EMAIL PROTECTED] > ><[EMAIL PROTECTED]> wrote: > >>Yeah this would be an extremely difficult problem. When Valve releases > SDK version N+1, you suddenly have to create a patch for your mod to take > you from N to N+1. That patch file is going to contain all the brand new > files in the SDK. > >> > >>Maybe I'm reading to much in to the earlier statements on this thread, > but it sounds like the patch files I posted on the wiki > http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List_Fixed a > while back are not kosher, since they contain all the new SDK files? > >> > >>If that's not the case, then an open source mod could conceivably > maintain an ongoing patch listing, given some known SDK as the starting > point. > >> > >> > >>At 2007/01/30 10:43 AM, Jeremy wrote: > >>>-- > >>>[ Picked text/plain from multipart/alternative ] > >>>Not sure how well that is going to work. I don't know how patch files > would > >>>deal the base SDK being changed during updates, and then users applying > the > >>>patches to a slightly different codebase than the patch was built from. > It's > >>>unfortunate they don't allow the code to be more public. Could open up > some > >>>neat opportunities like this. > >>> > >>>J > >>> > >>>On 1/30/07, Nikolaos Tzimoulis <[EMAIL PROTECTED]> wrote: > >>>> > >>>> Hello (again), > >>>> > >>>> I've started my open source mod on sourceforge. I figured out their > >>>> terrifying way of dealing with code submissions and now I'm working > on > >>>> a way to manage the code using diff files. I downloaded sfk (as Mike > >>>> suggested) and I understand that it can be used to apply patch files > >>>> to the original SDK files to generate the mod's source code. The > >>>> problem is that I can't find a way to automate the process of > creating > >>>> the patch file. Sfk needs a particular format and I need to get a > tool > >>>> that finds differences between files and saves the output in that > >>>> particular format. Should I try to make one on my own or is there a > >>>> tool to do that already out there? > >>>> > >>>> Also, to clarify on more thing: I'll just have to create an > unmodified > >>>> copy of the SDK code to use as a basis to create the patch, right? > >>>> > >>>> Thanks for the help and sorry for being a pest and asking questions > >>>> that aren't directly related to hlcoding. > >>>> > >>>> Nicholas > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> To unsubscribe, edit your list preferences, or view the list > archives, > >>>> please visit: > >>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>>> > >>>> > >>>-- > >>> > >>>_______________________________________________ > >>>To unsubscribe, edit your list preferences, or view the list archives, > please visit: > >>>http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >>_______________________________________________ > >>To unsubscribe, edit your list preferences, or view the list archives, > please visit: > >>http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > > > >_______________________________________________ > >To unsubscribe, edit your list preferences, or view the list archives, > please visit: > >http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
