[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