| 1 |
resurrecting this thread a bit late, but... |
| 2 |
|
| 3 |
On Thu, Dec 01, 2005 at 07:08:43PM +0100, Marius Mauch wrote: |
| 4 |
> emerge-webrsync is such a thing I'd rather |
| 5 |
> keep inline (should be subject for integration into emerge --sync |
| 6 |
> instead), |
| 7 |
|
| 8 |
Agreed, _long term_. Short term, till an actual sync refactoring is |
| 9 |
available, improvements I've pegged into emerge-delta-webrsync I'd |
| 10 |
like to move into emerge-webrsync. The main one is tarsync. |
| 11 |
|
| 12 |
Normal webrsync works by untarring to a tmp, then rsync'ing that onto |
| 13 |
$PORTDIR; hence tarsyncs existance, it bypasses the innefficient |
| 14 |
intermediate dumping of files, and does updates directly from the |
| 15 |
tarball to the tree. Sounds like something tar could do, but |
| 16 |
unfortunately tar lacks any syncing on disk dirs to match *exactly* |
| 17 |
the tarball- iow, files get left behind. |
| 18 |
|
| 19 |
Tarsync supports RSCYNC_EXLUDE syntax already, and for it's 4-6 month |
| 20 |
existance hasn't yet had a single bug via emerge-delta-webrsync |
| 21 |
testing- granted, not a huge userbase, but I'd peg it in the hundreds. |
| 22 |
|
| 23 |
So... thoughts? I'm not much for making portage depend on tarsync |
| 24 |
just for emerge-webrsync improvements, would rather chunk the bugger |
| 25 |
out. |
| 26 |
~harring |
Archives