Hi! The generated tarball is moved to $STATE_DIR, if the compressed md5sum differs. This is why the script should also try to remove old tarballs in $STATE_DIR. --- /usr/bin/emerge-delta-webrsync.~13~ 2005-05-30 08:55:22.000000000 +0200 +++ /usr/bin/emerge-delta-webrsync 2005-05-31 08:32:27.000000000 +0200 @@ -490,7 +490,7 @@ for x in $potentials; do echo "removing ${x}" rm "${DISTDIR}/${x}" "${DISTDIR}/${x}.md5sum" &> /dev/null - rm "${STATE_DIR}/${x}.md5sum" "${STATE_DIR}/${x}.umd5sum" &> /dev/null + rm "${STATE_DIR}/${x}" "${STATE_DIR}/${x}.md5sum" "${STATE_DIR}/${x}.umd5sum" &> /dev/null done fi echo "done." Best regards Christian
Hmm. Lets queue 'em up a bit, shall we? Any other bugs you've seen? I've been thinking about allowing variation on the compression settings to allow for faster sync'ings; currently the bzip2 -k9 gets backgrounded while tarsync does it's thing, but _only_ if tarsync is available. Thoughts?
(In reply to comment #1) > Hmm. Lets queue 'em up a bit, shall we? That's a good idea. > Any other bugs you've seen? Right now I haven't noticed another bug, but maybe tomorrow -- who knows? ;-) > I've been thinking about allowing variation on the compression settings to allow > for faster sync'ings; currently the bzip2 -k9 gets backgrounded while tarsync > does it's thing, but _only_ if tarsync is available. > Thoughts? I don't know how much impact this option would have on syncing speed, but it's definately worth a try. I guess that the improved syncing speed is a good tradeoff for the marginally gained size of the compressed tarball.
> I don't know how much impact this option would have on syncing speed, but it's > definately worth a try. I guess that the improved syncing speed is a good > tradeoff for the marginally gained size of the compressed tarball. Pardon the delay, been taking some majorly needed time off from gentoo and the computer as of late. The size bit is right, intention if I add it is to make it a knob so the user can turn down the compression if they desire. Re: syncing time, if tarsync is used, the tarball is recompressed in the background while tarsync does it's thing; multi proc systems, makes a decent difference synce wise, so the gain wouldn't be massive. It would, however, be useful for low end systems I'd think.
(In reply to comment #3) > It would, however, be useful for low end systems I'd think. I'm emerge-delta-webrsync'ing right now, and I think it would also be useful, if nice-values for the applications emerge-delta-webrsync starts could be set (either via command-line switch or configuration file). On my Duron 1300 my mouse pointer is skipping during syncing. (Some minutes later:) On second thought... I could simply start emerge-delta-webrsync with nice, and the above problems would be gone! ;-) Or should PORTAGE_NICENESS be used?
PORTAGE_NICENESS would require some trickery, basically re-execing emerge-delta-webrsync which is nasty :) I'll poke into it however.
(In reply to comment #5) > PORTAGE_NICENESS would require some trickery, basically re-execing > emerge-delta-webrsync which is nasty :) You could renice the script. Should work also...
released as 3.3, w/ hard tarsync dep for x86 and stabled niceness bit, will look at it when I get time (lacking time atm).
