<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jul 17, 2008 at 11:18 AM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Thu, Jul 17, 2008 at 5:11 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br>
> Actually, I have one more concern. It seems to me we might be better off<br>
> checking against a hash of the file, instead of a timestamp. We don't want<br>
> to continually merge new favorites with every OS update, but that's exactly<br>
> what we'll do if we only check the timestamp on the favorites.default file,<br>
> right? By checking a hash, we ensure that someone (either us, by "shipping"<br>
> a new favorites.default, or the country, via a customization key) intended a<br>
> new merge to happen.<br>
<br>
</div>Well, what if the country removed an activity because it's no longer<br>
shipped, do we still want to add the rest of the activities that the<br>
user unfavorited? I'm not sure it's worth going to such details right</blockquote><div><br></div><div>This isn't handled by either approach. Both the timestamp and the contents would be updated in this scenario, and we'd merge the defaults in either case.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
now, even more when laptops will be updated at most twice per year.<br>
Also, at this point in the release, pushing patches is quite<br>
expensive. But enter a ticket if you really want this in a future<br>
release.<br></blockquote><div><br></div><div>It might be true that this one isn't as serious for kids in countries. It will be a real pain for developers worldwide, though, if they are updating to new cutting edge builds and constantly having the defaults merged back.</div>
<div><br></div><div>- Eben</div><div> </div></div></div>