Should support pushing diffs only and not require upload of entire project

[phoneboy]

My projects are several hundred megabytes. Uploading the entire thing each time I make a change seems utterly wasteful.

[brandonb927]

Edit: After a long time of surge use, I want to rescind my +1 as I understand what Surge should and shouldn't do more clearly.

---

+1 👍 Would love this! I have a blog that is constantly growing in size due to images, coupled with my internet connection at home for uploads being utter shit.

[cfjedimaster]

+1

[silentrob]

So just a little sidebar. The upload process right now compresses and streams the entire contents without writing any files to disk. Once the files are uploaded to our initial staging server, they are sent to a CDN fleet. That step uses a rsync like process.

We looked into rsync'ing the first step but it added significat complexity and we didn't want to delay the launch at the time. We also acknowledge the primary persona would not have been effected dramatically by this body of work.

Having said that. I think it is something that should still get done.

[jokeyrhyme]

Is there a way to do a dummy-run, to see which resources would be different if a real publish action were executed? Is there an API that returns all the hashes / Etags of all currently-published resources?

[nscobie]

+1

[dtinth]

@jokeyrhyme auto.appcache file contains the hashes (and size) of all the files.

---

I solved this problem by rsyncing to a $5 DigitalOcean and then executing surge there. Here’s my drop-in replacement shell script.

#!/bin/bash
if [ "$1" -a "$2" ]
then
  rsync -avz --delete "$1/" "$REMOTE_SERVER_HOST:/surge/$2"
  ssh "$REMOTE_SERVER_HOST" surge "/surge/$2" "$2"
else
  echo 'usage: surgeup [project path] [domain]'
  exec false
fi

[phoneboy]

You're moving the problem somewhere else.
It doesn't solve the underlying problem.

On Mon, Jan 4, 2016 at 6:52 AM, Thai Pangsakulyanont <
notifications@github.com> wrote:

@jokeyrhyme https://github.com/jokeyrhyme auto.appcache
https://davidwalsh.name/dont-wait-serviceworker-adding-offline-support-oneline

file contains the hashes (and size) of all the files.

I solved this problem by rsyncing to a $5 DigitalOcean and then executing
surge there. Here’s my drop-in replacement shell script.

#!/bin/bashif [ "$1" -a "$2" ]then
rsync -avz --delete "$1/" "$REMOTE_SERVER_HOST:/surge/$2"
ssh "$REMOTE_SERVER_HOST" surge "/surge/$2" "$2"else
echo 'usage: surgeup [project path] [domain]'
exec falsefi

—
Reply to this email directly or view it on GitHub
#119 (comment).

[dtinth]

@phoneboy I agree that the underlying problem still isn’t solved and this issue should remain open, but DigitalOcean has a pretty decent bandwidth with surge.sh.

My internet connection here isn’t so good, so using DigitalOcean as a middle man sped up my deployment greatly. What took me a minute now takes seconds.

[gemedet]

+1

[stuartbreckenridge]

+1

[edwardabraham]

We are using Firebase for deploying a static site, and are seeking a static file host who solves this specific problem (Divshot used to support incremental upload, which was awesome, but it was deprecated when they were acquired by Firebase). It currently takes 8 minutes to deploy our website, which is a long time when you have updated a few typos. If Surge made incremental updates available, we would switch right away.

[brandonb927]

@edwardabraham are you uploading images or anything to the site? Surge is mostly for just hosting static JS/CSS/HTML assets and not particularly suited for hosting tonnes of images.

[edwardabraham]

That is the problem, we have a big pile of PDFs on our site. A solution
would be to re-engineer it so that those were hosted on Amazon or somewhere
else, but that would make things more complicated ...

On 12 April 2016 at 10:44, Brandon Brown notifications@github.com wrote:

@edwardabraham https://github.com/edwardabraham are you uploading
images or anything to the site? Surge is mostly for just hosting static
JS/CSS/HTML assets and not particularly suited for hosting tonnes of images.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#119 (comment)