On Jul 6, 2007, at 01:07, Juan Manuel Palacios wrote:
The reason why you now see the full list of ports when you sync
your tree, as opposed to a delta with only the files that have seen
changes since your last sync, is that I changed the way in which
the rsync repos feeding your ports and base trees are populated.
The operation used to involve an svn checkout of the ports and
base trees and then an rsync (excluding certain files and dirs)
from that checkout onto the rsync repos, wherefrom users get them
through sync/selfupdate.
Now we don't just rsync the svn checkout onto the rsync server
with some particular flags to exclude files we don't want in there,
like .svn control dirs, but instead we "svn export" the trees to
prepare them in a more formal fashion before pushing them to the
rsync server. That operation presumably resets a timestamp on each
file and dir and that's why you pull the entire thing again when
you sync/selfupdate after each half an hour (the periodicity of the
rsync server re-population).
Ah, I see now: the list printed is the list of items with differing
modification timestamps. Because the svn export is recreated every
half hour, the modification timestamps of all items vary every half
hour as well.
In other words, we were preparing the rsync repos rather manually
before and now we let "svn export" do that for us. The entire
process is described in the script I re-wrote and in the config
file detailing the rsync server setup:
http://trac.macports.org/projects/macports/browser/trunk/base/
portmgr/mprsyncup
http://trac.macports.org/projects/macports/browser/trunk/base/
portmgr/rsync.repos
Improvements to the mprsyncup script are welcome, I personally
don't like pulling the entire thing over and over again after every
half an hour either, but I do like relying on "svn export". I'm
sure there are rsync flags we could use to recover the delta part
of the old behavior while still keeping "svn export", but I just
haven't had the time to investigate. Again, suggestions/
improvements are welcome! ;-)
So, why are you so keen on using svn export, when it causes the above
issue? I recommend using an rsync command instead of svn export. It
should work the same, except that it will avoid the above issue. See
this message:
http://svn.haxx.se/users/archive-2006-06/0971.shtml
Or, is that what the script was doing before? If so, again, why did
you want to change it?
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users
