Thread: Helmi Official AKU 3.5 Kitchen 1.0.2 Bugs / Patches
View Single Post
  #225 (permalink)  
Old 07-27-2007, 06:39 PM
gguruusa's Avatar
gguruusa
Deep Thinker
Offline
Location: Mountain top
  
Join Date: Jan 2007
Posts: 3,252
Reputation: 4726
gguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributions
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quote:
Originally Posted by Kolano
Quote:
Originally Posted by gguruusa
Quote:
Having an "override" folder to drop updates in that would override existing items, instead of mixing everything into the OEM folder might be a good solution.
Assuming you haven't renamed or moved around kitchen directories,
1. Load the new kitchen into a different directory than the old kitchen
2. select all the directories in the old kitchen OEM folder
3. copy and paste the old OEM folder directories into the new kitchen OEM folder. Select "no to all" when it asks about replacing existing directories.

If it doesn't go smoothly (BuildOS fails), finding the conflicts between the old and new OEM folders can be time consuming.
This isn't a good solution, as it's prone to blow away change made in the newer kitchen.

Quote:
Originally Posted by luv2chill
A beter solution for transitioning between kitchens is to give all of your "portable" OEMs a unique foldername. Prefix them with "X_" or even "Custom_". BuildOS doesn't care what the folder is named so if you title them all with a single prefix at least they will all be grouped together.
I've done this, but this solution only works well for additions to the kitchen, not revisions to existing content. I have taken a similar tact when making revisions to existing content (i.e. renaming the old folder with my Kolano_ prefix to differentiate it from the kitchen version), but when doing this I need to re-analyze each of OEM during a kitchen updte to ensure I don't miss something revised in the newer kitchens.

Is "bepe" a user on this forum, luv2chill? If not where is he/she from?

I was hopeful, with the recent revisions to support the option.xml files, that active development of the BuildOS tool was still going on. If it is I would love to see some override mechanism implemented.
Bepe is on vacation, and from the looks of things, busy with more technical kitchen changes (for other phones). He's the creator/owner of BuildOS.

When you say "no to all" during the copy, it preserves the new kitchen at the expense of the old kitchen folder. So long as the kitchens are based on the same core, this will result in folders you've added to the old kitchen being added to the new kitchen (ignoring certs.oem - it shouldn't change anyway)

There's no way to avoid the analysis part if you make your own custom mods to a kitchen folder. WinDiff is your friend. In most cases, you can put the mods you'd make in a custom settings OEM - just make sure it has a late GUID (like FFFFFFF.....).

The FileDialogChanger 1.66 I have didn't come from the 1.02 kitchen. It either came from the zip at the start of this thread or Colonel's ftp, can't recall which. It has an exception entry in it for regedit.
Reply With Quote