A common case for io.Writer errors is during noms-log or noms-show when
piped through head, i.e. "noms log ldb:/path/to:noms | head".
noms-log handles this itself by recovering from the panic, but rather
than porting this logic to noms-show, just make it so that you don't
need to recover in the first place.
This is similar to how errors from fmt.Println etc don't panic.
Non-write errors (like crashes) will continue to panic.
The old timeout mechanism started counting when the client
began trying to connect to the server. This meant that sending
a large batch of chunks could cause the request to fail before
all the data even made it to the server. What we actually want
is to timeout when the connection has been idle for some amount
of time. This means that long server processing times can still
cause clients to time out, but that's probably as it should be.
Towards #1414
This is to support efficient chunk diff. Most of the churn in this patch
comes from updating test expectations, and updating every Ref construction
to include a height and every MetaTuple to include a Ref.
A novel chunk may contain references to any other novel chunk, as long
as there are no cycles. This means that breaking up the stream of
novel chunks being written to the server into batches risks creating
races -- chunks in one batch might reference chunks in another,
meaning that the server would somehow need to be able to
cross-reference batches. This seems super hard, so we've just forced
the code to write in one massive batch upon Commit(). We'll evaluate
the performance of this solution and see what we need to change.
Also, there's a terrible hack in HandleWriteValue to make it so that
pulls can work by back-channeling all their chunks via postRefs/ and
then writing the final Commit object via writeValue/
This can be fixed once we fix issue 822
* Implement noms-view and make splore compatible
* Comments
* npm test
* Fewer changes to readme/build/etc
* comment in noms_view.go
* More updates
* Typo
