On Jul 16, 2007, at 2:24 PM, markd@macports.org wrote:
If I understood this better perhaps I could write it up in the new guide. When did this function become available? What do we call it? Remote repository? Is it basically an internal macports repository for the enterprise? Are the comments in mprsyncup and rsync.repos the only documentation we have?
Mark
Hi Mark! Thanks for inquiring about this, I was just about to write to you to request inclusion in the new guide ;-) The base/portmgr/mprsyncup and base/portmgr/rsync.repos files explain in their comments all that's needed to replicate our rsync mirrors locally, for instance on a server that wishes to supply local clients with faster sync/ selfupdate functionality off its own rsync server (not having to travel all the way to California if you're around the globe). Note that this is not exactly mirroring, as the example server would be doing the exact same thing rsync.macports.org is doing when setup with those two files, but independently of it (therefore "replicating"). Vlad recently mailed portmgr about the "mirroring" topic, which is what prompted me to better explain the procedure in the files. The two thing I forgot to say to him in my reply is, one, that clients wanting to use the replicating server should be properly configured to do so: -) rsync_server in macports.conf & rsync:// url in sources.conf: reset to point to your local server, not rsync.macports.org -) rsync_dir in macports.conf & path component in rsync:// url in sources.conf: these shouldn't need any modifications if you follow the default and official repositories the MacPorts project offers on its own rsync server (coded in both base/portmgr/mprsyncup and base/ portmgr/rsync.repos); adapt accordingly otherwise (we assume you know what you're doing if you go to the trouble of offering other rsync repositories). And two, anyone wanting to replicate our configuration should consult with portmgr@ on an appropriate periodicity, we don't want to hammer the svn server too bad (every replicating server would be pulling from there). We refresh every 30 minutes at each x:00 & x:30, so we would appreciate it if 3rd parties didn't replicate more often than that and a bit off those two marks in any case. It would be great if all this information (including the comments in the two files in svn) were incorporated into the new guide! Lastly and with respect to the new guide's source: could you, Mark, please split it up in logical xml files (as you asked a while ago and as the current guide exists in svn) rather than having it in just one big monolithic file? Seems to me like it's much easier to handle like that. Regards,... -jmpp PS: Another topic that's up for inclusion in the new guide are the new ticketing guidelines that we're currently discussing on -devel@. I'll try to reply ASAP to the feedback I've received (thanks a bunch!) and will also setup a new Wiki doc (NewTracTicketing) to hold a mockup of the final design and consensus (currently smeared among a few mail posts, hard to track). Once that's done I'd like to see that text fully expanded into the new guide, please ;-), and NewTracTicketing removed, while the existing one (TracTicketing) should be turned into either a URL forward to the guide docs (once they're setup) or simply slimmed down with a single "Read all about it here <url>" line. Thanks!