I (Julian Foad) wrote:
> Vincent Lefevre wrote:
>> On 2013-03-05 13:30:28 +0000, Julian Foad wrote:
>>> Vincent Lefevre wrote:
>>>> On 2013-03-01 14:58:10 +0000, Philip Martin wrote:
>>>>> A server-side solution is difficult. Suppose the client has some
>>>>> uncompressed content U which it compresses to C and sends to the server.
>>>>> The server can uncompress C to get U but unless the compression scheme
>>>>> has a canonical compressed form, with no other forms allowed, the server
>>>>> cannot avoid storing C because there is no guarantee that C can be
>>>>> reconstructed from U.
>>>>
>>>> This is not specific to server side. Even on the client side, the
>>>> reconstruction may not be always possible, e.g. if the system is
>>>> upgraded or if NFS is used. And the compression level may need to
>>>> be detected or provided in some way.
>>>
>>> Hi Vincent. I'm not sure you understood Philip's point.
>>
>> This should be more clear about what I meant below. What I'm saying is
>> that whether this is done entirely on the server side (a bad solution,
>> IMHO) or on the client side (see below why), the problems are similar.
>
> The point Philip made is *not* a problem if done client-side;
Let me take that back. The point that I interpreted as being the most significant impact of what Philip said, namely that the Subversion protocols and system design require reproducible content, is only a problem when done server-side. Other impacts of that same point, such as you mentioned, are applicable no matter whether server-side or client-side.
Sorry for stubbornly applying my own interpretation there.
> some of the
> *other* problems are similar no matter on which side we would do the
> expansion/compression.
>
>>> His point is (correct me if I'm wrong) that Subversion's design
>>> requires that during a checkout or update, the server must
>>> reconstruct a file containing exactly the same bit pattern that the
>>> client sent when committing the file. Compression schemes in
>>> general don't guarantee that expanding and then compressing will
>>> produce the same compressed bit pattern, even if you take care to
>>> use the same "compression level". Therefore, the server cannot
>>> simply expand the data before storing it and then re-compress it
>>> during checkout or update, because, although the resulting
>>> compressed file would be a valid representation of the user's data,
>>> it would not satisfy Subversion's own requirement that the bit
>>> pattern be identical to what was sent by the client during the
>>> commit.
>>
>> You say that the server expands the data before storing it. This is
>> for a server-side only solution, I assume.
>
> Yes, I'm talking about the server-side-only solution, which is one of the
> hypothetical solutions that we are discussing and comparing.
>
>> But even if there would
>> be no problems with the construction/reconstruction, it would be a
>> bad solution, IMHO. Indeed, for a commit, it is the client that is
>> supposed to expand the data before sending the diff to the server,
>
> What do you mean "the client [...] is supposed to expand the data"? I
> don't understand why you think the client is "supposed" to do such
> a thing.
>
>> and for an update, it is the client that is supposed to recompress
>> the data before storing it to the WC. Actually, the server doesn't
>> need to know how the file was compressed, it just needs to record
>> information about the compression (but doesn't need to know what
>> this means exactly).
>>
>>> That point _is_ specific to a server-side solution. With a
>>> client-side solution, the user's word processor may not mind if a
>>> versioning operation such as a commit (through a decompressing
>>> plug-in) followed by checkout (through a re-compressing plug-in)
>>> changes the bit pattern of the compressed file, so long as the
>>> uncompressed content that it represents is unchanged.
>>
>> I disagree.
>
> It's not clear what you disagree with.
>
>> The word processor may not mind (in theory, because
>> in practice, one may have bugs that depend on the bit pattern,
>> and it would be bad to expose the user to such kind of bugs and
>> non-deterministic behavior), but for the user this may be important.
>> For instance, a different bit pattern will break a possible signature
>> on the compressed file.
>
> I agree that it *may* be important for the user, but the users have control so
> they can use this client-side scheme in scenarios where it works for them and
> not use it in other scenarios.
So my main point is that the server-side expand/compress is a non-starter of an idea, because it violates basic Subversion requirements, whereas client-side is a viable option for some use cases.
- Julian
Received on 2013-03-05 18:10:43 CET