Summary:
Fixes T10509. Pushing changes to staging can be inefficient. What happens, roughly, is:
- Master is at commit "W" -- "W" is the most recent published commit in the main repository.
- The local working copy has one change on top of that, "X", so its history is commits "A, B, C, D, E, F, ..., U, V, W, X".
- The remote has some other previous changes that I or other users have made, maybe like "A, B, C, ..., S, T, U, Y" and "A, B, C, ..., T, U, V, Z", from previous pushes to staging areas.
- "X", "Y" and "Z" will never actually make it to master, because they'll be squash-merged/amended by `arc land`.
So the local says "I want to push 'X'", and the remote says "I know about 'Y' and 'Z', are those in the history of 'W'? You only need to send me new stuff if they are".
But they aren't, so the local says "nope, so here's the whole history for you". This is slow and sends a ton of data that the remote already has over the network.
In theory, Git could use a slightly different algorithm to tell the local about more commits, but this is hard, rarely useful, and not the kind of thing I'd be excited about changing if I was the Git upstream.
Instead, when pushing "X", also push "W", to trick Git into telling future clients about it.
Now, the remote should say "I know about 'W', 'Y' and 'Z'", and the local will say "oh, great, 'W' is in history, here's just the changes since then".
Also, fail `arc diff` if the push to staging fails, and tell users to use `--skip-staging`. This code has been in production for a while and doesn't seem to have any issues, and a failed push to staging prevents builds, lands, etc.
Test Plan:
- Ran `arc diff`, saw two changes push.
- Ran `arc diff --base arc:empty`, saw only one change push.
- Ran `arc diff` with an intentionally broken staging area, saw an error.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10509
Differential Revision: https://secure.phabricator.com/D15424
Summary: Ref T7148. In D14056, I let `arc upload` upload temporary files, but this is a better way to do some of the internals. Also add support for setting a `viewPolicy`.
Test Plan: Used `arc upload`, `arc upload --temporary`.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7148
Differential Revision: https://secure.phabricator.com/D14075
Summary: Ref T7148. Depends on D14055. Allows files to be marked as temporary when uploaded.
Test Plan: Used `arc upload --temporary` to upload temporary files.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7148
Differential Revision: https://secure.phabricator.com/D14056
Summary: Fixes T8259. Depends on D13016. Use modern logic to support large file uploads.
Test Plan:
- Diffed with some images, saw them show up in the diff.
- Diffed with a 12MB binary, saw it upload in chunks.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8259
Differential Revision: https://secure.phabricator.com/D13017
Summary:
Ref T8259. Currently, `arc upload` uses new logic but `arc diff` uses older logic internally. This prevents `arc diff` from uploading files larger than 4MB to newer servers.
Split the upload logic apart so the two upload pathways can share it. Callers now build a list of FileDataRefs and hand them to an Uploader for upload.
Test Plan:
Ran `arc upload` on:
- One file.
- Several files.
- Small files.
- Big files.
- Directories.
- Unreadable files.
- Files full of random data.
- The same file over and over again.
- The same big file over and over again.
- Artificially broke `file.allocate` and redid some of the simple cases (large/chunked aren't expected to work in this case).
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T8259
Differential Revision: https://secure.phabricator.com/D13016
