[darwinbuild-dev] How to find build version difference
Kevin Van Vechten
kvv at apple.com
Wed Jan 9 14:39:41 PST 2008
DBCopyProjectNames() always returns a sorted list.
On Jan 9, 2008, at 2:15 PM, BuildSmart wrote:
> Michael, looking at the provided example I was wondering if there
> might be an issue where a project in a does not exist in b and a
> project in b does not exist in a but I think the recursive loop will
> catch this variance but I was more concerned about the order of the
> data in the plists and while I see that for the most part they are
> sorted I was wondering if something out of order might cause a
> problem.
>
> In a small test I created two plists, changed the order in the
> second without adding or removing projects and the diff results were
> not what I expected, they should have been identical so a little
> more code will be required to compensate for variance in content
> order so that projects don't get skipped unless the general
> consensus is that order will always be sorted and shouldn't become
> an issue of concern.
>
> -- BuildSmart
>
> On Jan 9, 2008, at 14:22:01, Kevin Van Vechten wrote:
>
>> This is looking good, and I'm happy to see you contribute code to
>> the project. As an optimization, we can take advantage of the fact
>> that DBCopyProjectNames() returns a sorted list to detect missing
>> projects in either build in a single pass (pseudo code below). By
>> comparing in this way, we don't need to do the extra merge and sort
>> found in get_project names, and we don't have to do as many
>> database lookups to see if the project really exists in that build.
>>
>> On a different topic, it's easiest for us to accept your
>> contributions if you place a license header (preferably the same
>> BSD-style license DarwinBuild already uses) and your copyright on
>> the top of the file. Believe it or not, that's more
>> straightforward than simply saying the code is free to use.
>>
>> Thanks,
>>
>> - Kevin
>>
>> alist = DBCopyProjectNames(abuild);
>> blist = DBCopyProjectNames(bbuild);
>>
>> int i = 0, j = 0;
>>
>> for (;;) {
>> CFStringRef a = CFArrayGetValueAtIndex(alist, i);
>> CFStringRef b = CFArrayGetValueAtIndex(blist, j);
>>
>> CFComparisonResult res = CFStringCompare(a,b,0);
>>
>> if (res == kCFCompareEqualTo) {
>> // both builds have the same project, let's compare versions
>>
>> av = DBCopyPropString(abuild, a, CFSTR("version"));
>> bv = DBCopyPropString(bbuild, b, CFSTR("version"));
>> res = CFStringCompare(av,bv,0);
>> if (res == kCFStringCompareEqualTo) {
>> print "same";
>> } else {
>> print "different";
>> }
>>
>> // move both lists to next project
>> ++i;
>> ++j;
>>
>> } else if (res == kCFCompareLessThan) {
>> // a fell behind b, which means b is missing a project
>>
>> print "project A only in build A";
>>
>> // only increment a, so that it catches up to b
>> ++i;
>> } else if (res == kCFCompareGreaterThan) {
>> // a got ahead of b, which means a is missing a project
>>
>> print "project B only in build B";
>>
>> // only increment b, so that it catches up to a
>> ++j;
>> }
>>
>> // we're done if we reach the end of both lists, otherwise
>> // make sure we don't march past the end of one
>> if (i >= acount && j >= bcount) break;
>> else if (i >= acount) i = acount -1;
>> else if (j >= bcount) j = bcount -1;
>> }
>>
>>
>> On Jan 8, 2008, at 6:22 PM, Michael Franz wrote:
>>
>>> Kevin,
>>>
>>> thanks for the input. I had already figured out that I was not
>>> getting the correct information from the plists. I was only get the
>>> project plist which was missing inherited projects. I have
>>> changed it
>>> to use code from the version plugin instead.
>>>
>>> On 1/8/08, Kevin Van Vechten <kvv at apple.com> wrote:
>>>> Michael's plugin is a good start, however copying the whole Build
>>>> plist (with all project attributes) to inspect it is a rather
>>>> heavyweight process. It's possible to use the plugin API to search
>>>> the data in the sqlite database. The use of this API also
>>>> answers the
>>>> question below.
>>>>
>>>> On Jan 7, 2008, at 7:45 PM, Michael Franz wrote:
>>>>
>>>>> I found a slight bug in my implementation. I do not use a
>>>>> complete
>>>>> set of project names, so, when the src build has many more
>>>>> projects
>>>>> than the destination the diff is incorrect. I am currently
>>>>> looking at
>>>>> a way to create a set of the two build project names. This way
>>>>> I will
>>>>> have a complete set of all projects in both builds.
>>>>
>>>> CFArrayRef DBCopyProjectNames(CFStringRef build);
>>>>
>>> Using this instead as stated above.
>>>
>>>> This function returns an array of all projects in the given build
>>>> (including inherited projects). I believe this is already
>>>> sorted, but
>>>> I'm not 100% sure.
>>>>
>>>> There's also the following function which you might be interested
>>>> in:
>>>>
>>>> CFArrayRef DBCopyChangedProjectNames(CFStringRef oldbuild,
>>>> CFStringRef
>>>> newbuild);
>>>>
>>> I 'll look into that function.
>>>
>>>> Also it's not clear to me why DBSetPlist() is called at the
>>>> end... I
>>>> don't think of "diff" as a mutagenic operation.
>>> That was a line that I did not delete - it is from mergeBuild.
>>>
>>> I have removed it, as I also found it earlier and couldn't
>>> understand
>>> why it was there.
>>>>
>>>> - Kevin
>>>>
>>>
>>> Here is a (almost) rewritten version of the plugin.
>>>
>>> Michael
>>> <diff.c>
>>
>> _______________________________________________
>> darwinbuild-dev mailing list
>> darwinbuild-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/darwinbuild-dev
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/darwinbuild-dev/attachments/20080109/bc53cb1e/attachment-0001.html
More information about the darwinbuild-dev
mailing list