Re: [gentoo-dev] updated gentoolkit with echangelog modification

[Evan Powers]

On Monday 28 April 2003 09:29 am, Nicholas Wourms wrote:
> do things.  Later, I realized the other way, but I became
> convinced that the "new" style made more sense.
...
> Can you provide some arguments why
> the old style is more proper then the new style?  Does it
> scale well?  Which makes more sense in the short-term until
> a more permanent, extensible format can be developed?  I'd
> like to hear your views on readability.

The more I think about it, the more I think the "old" style is ultimately a 
better native storage format, and the less I agree with you about the 
scalability of the "new" format. I'll argue my point by discussing how to 
perform the different operations one performs on a change log.

The short summary of the following is that with the "old" style:
1) you can leverage existing software or write simple software to mitigate the 
conveniences of the "new" format
2) with the "new" format, you have to write more complicated software to 
mitigate the conveniences of the "old" format; existing software is not much 
help
3) as the log grows, the time required to perform operations on the "new" 
style is at least O(n) worse (assuming O(n^3)/O(n^2) = O(n)) than the same 
operation on the "old" style

The operations are:
1) adding a new entry which touches one ebuild
2) adding a new entry which touches several ebuilds
3) extracting the most recent changes of a particular ebuild
4) extracting the most recent changes across all ebuilds
5) more complicated operations:
	a) changes made by a developer
	b) changes made within a time range
	c) ...

Let's assume that we're willing to use software to help us, and write it if 
necessary, in order to hit the optimal native format.

OK, sort-of-big-O analysis of operations on the "old" format (n is the number 
of entries in the changelog, e the number of ebuilds):
1) O(1) [just add it to the top]
2) O(1)
3) O(n) [iterate over the n entries and print those against the specified 
ebuild]
4) O(1) [just take the top few]
5)
	a) O(n) [iterate over the n entries and print those by the developer]
	b) on average, O(n/2) [find the beginning of the range and print it]

Note that, for each query operation:
1) "less ChangeLog", run a / search will work
2) "grep -A nnn" almost works
3) only need simple awk/perl to extract the result

sort-of-big-O analysis of operations on the "new" format:
1) on average, O(n/2) [have to find the ebuild section]
2) O(n) [not cleanly possible, unless you duplicate the log in each section or 
split it apart and tag each piece with something unique to the original 
changeset]
3) on average, O(n/2) [have to find the ebuild section]
4) O(n*log(n)) [have to resort the entries; assume best known sorting algo.]
5)
	a) O(n^2*log(n)) [have to iterate over entries to find those by a particular 
developer (number presumably proportional to n), then sort them]
	b) about O(n^2*log(n)) [similar to 5a]

Note that the new format is never more efficient than by a coefficient, and is 
in general significantly worse. Further:
1) less searches are useless
2) "grep | sort" will give you the line numbers
3) awk/perl software doubles in complexity (as measured by L.O.C.)

Evan

--
gentoo-dev@g.o mailing list