GSoC Update: Registry

[Chris Pickel]

On 03 Aug, 2007, at 16:02, Juan Manuel Palacios wrote:
>> I've also written a script to up-convert a user's existing  
>> receipts/filemap into the new format. It's reasonably fast (and  
>> was not so before I got smarter with sqlite transactions).
>
> 	How would that script be run? Each user manually at their own  
> discretion? Or through some upgrade glue internal to MacPorts? I  
> would very much prefer the latter approach, something like my  
> "upgrade" target in base/Makefile.in (later on I'll remove all that  
> code once we consider enough time has gone by to upgrade most of  
> our user base to the macports namespace, in the mean time I'm sure  
> we can share that target for other upgrade purposes).

I had assumed an 'upgrade' target. However, since the script is  
external to the Makefile, it wouldn't be difficult to do the second  
method - i.e., at the end of mportinit, if file doesn't exist $ 
{registry.path}/registry/, source ${prefix}/share/macports/scripts/ 
reg_upgrade.tcl

>> The Tcl code that makes *use* of the registry has not yet been  
>> modified. So, I could commit registry2 now without screwing  
>> anything up
>
> 	Not sure what you mean by this. What hasn't been modified and  
> where? You mean that if you commit registry2.0 now, trunk would  
> still be using the old registry & filemap until you "hook up" your  
> code?

Exactly. The APIs are similar, but not identical.

>>  * I don't feel there's a need to include it in 1.5.1. If someone  
>> wanted to go ahead and tag 1.5.1, that'd be great :)
>
> 	I'm working my way toward 1.5.1, hopefully soonish now (targeting  
> mid next week). But, likewise, nothing to worry about here, I'm  
> working with the sweet svnmerge.py on the 1.5 branch so I can  
> cherry pick what we merge in from turnk and what stays out. Also,  
> the release tags are created off release branches, not trunk, so  
> that's more leeway there.

OK. So to be clear, if I commit to trunk, there will be no trouble  
with keeping it out of 1.5.1? Then I'll go ahead and commit.

>>  * Documentation. cregistry is largely documented, in the doxygen  
>> style, but I'm not sure of the best way to document registry2.0. I  
>> could do a manpage (but what to call it?), or more doxygen-style  
>> (but tools would confuse the C parameters of the actual functions  
>> with the Tcl parameters I'd document).
>
> 	I'd encourage you to do the same for registry2.0 and later on  
> figure out what tool we use to produce the docs if doxygen can't  
> handle the tcl format, what matters the most is that the  
> documentation is already there in place.

Alright. I think I'll probably use the doxygen style, but use /*  
instead of /**. Tools won't detect it as documentation, so they won't  
screw up when they try to associate it with the function signature ;)


Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070803/ef333d3e/PGP.bin