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