dSYM status report and proposal

[Augie Fackler]

On May 29, 2009, at 8:18 PM, Peter Hosey wrote:

> On May 29, 2009, at 06:32:55, Zachary West wrote:
>> In either case, the binaries *do* need to be version controlled.
>
> The system I proposed is basically a very stripped-down centralized  
> version-control system. No branches, tags, merging, etc. The build  
> numbers are revision numbers.
>
>> If any works is involved in upping these builds …
>
> (i.e., committing. ☺)
>
> That is the hard part. scp?
>
>> (such as manually creating this buildinfo file)
>
> The buildinfo file would be in the Frameworks directory. You  
> wouldn't have to create it, merely update it. We could have a tool  
> in Utilities for that, as well (similar to the one for updating the  
> appcasts, only without the janky XML non-parsing).
>
>> It doesn't seem all that costly to include the binaries in hg  
>> though, but libpurple updates are a decent chunk of change (maybe  
>> 1-2MB each).
>
> As David already noted, it is about 2 MiB (1.75 MiB in my test).  
> That's for every Libpurple update. It'd be more in instances where  
> we also update some of the dependencies, such as glib.
>
> Your suggestion of a separate hg repository is thought-provoking. On  
> the one hand, hg's deltaification will help conserve disk space on  
> the server. On the other hand, each of us would need to download all  
> past Libpurple builds, or explicitly copy the Libpurple-builds  
> clone, any time we cloned our local Adium repository; currently,  
> Libpurple-build history comes along for the ride, and in the system  
> I proposed, we'd need to download or copy *only* the current build.

subrepo support (similar to but better than svn:externals) is planned  
as part of Mercurial 1.3, due out in July. That would make this much  
easier to maintain and follow which libpurple belonged where.

> But then there's the question of keeping it synchronized with  
> Adium's repository. Currently, when you update, a new Libpurple may  
> come along as part of that. If we have a separate hg repository that  
> you need to clone into the right place, you would either need to  
> update it manually or update it at every build time. The latter  
> solution wouldn't even work, as you couldn't update to old Adium and  
> have the matching Libpurple.
>
> We could combine the two: Use hg on the back end, and have download- 
> build-info obtain each build by downloading an archive URL (http://hg.adium.im/libpurple-et-al/archive/$NUM.zip 
> ).
>
>