Feature request: new svn_delta_action zero_bytes

["Ph. Marek" <ph...@bmlv.gv.at>]

Hello everybody,

I have a feature request: I'd like to have a new enum svn_delta_action named 
zero_bytes or something similar, which could be used eg. for sparse files, to 
save time and bandwidth.

Is that a bad idea, or shall I create an issue?


Thank you.


Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: new svn_delta_action zero_bytes

[Greg Hudson <gh...@MIT.EDU>]

On Thu, 2006-03-02 at 12:23 +0100, philipp.marek@bmlv.gv.at wrote:
> I know that GNU tar and cp have special code for finding ranges of 0-bytes, but
> that's I'd like to encode that distinctly - it's a good documentation, and
> makes handling easier.

But it makes transition much harder.  Older code wouldn't be able to
understand the new encoding of 0-byte ranges.

Just create a writable stream, similar to svn_stream_from_aprfile, which
detects runs of 0 bytes and lseeks instead of writing them.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: new svn_delta_action zero_bytes

[ph...@bmlv.gv.at]

> Ph. Marek wrote:
> > Hello everybody,
> >
> > I have a feature request: I'd like to have a new enum svn_delta_action
> named
> > zero_bytes or something similar, which could be used eg. for sparse files,
> to
> > save time and bandwidth.
> >
> > Is that a bad idea, or shall I create an issue?
> >
> Did you actually see a significant performance problem?
>
> If you have a (new) range of zeroes in the target stream, the delta for
> it should look like this:
>
>     new-data "\0"
>     target-copy -1 <length of range -1>
Yes, I read that in svn_delta.h.

> You'd get two instructions instead the ideal one, but the zeroed range
> is still run-length encoded in practice.
>
> I fail to see what that has to do with sparse files, though. Are you
> implying that Subversion should create sparse files on the client if
> they're supported? If so, that's entirely independent of the deltas.
What I meant (but probably failed to say :-) is that if there's a special
encoding for zero-byte ranges the client can just lseek() (and create sparse
files) instead of writing many zero bytes.

I know that GNU tar and cp have special code for finding ranges of 0-bytes, but
that's I'd like to encode that distinctly - it's a good documentation, and
makes handling easier.


But I know that it could be encoded in other ways, and possibly the work
involved (and problems with backporting etc.) is too much.


Thank you!


Regards,

Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature request: new svn_delta_action zero_bytes

[Branko Čibej <br...@xbc.nu>]

Ph. Marek wrote:
> Hello everybody,
>
> I have a feature request: I'd like to have a new enum svn_delta_action named 
> zero_bytes or something similar, which could be used eg. for sparse files, to 
> save time and bandwidth.
>
> Is that a bad idea, or shall I create an issue?
>   
Did you actually see a significant performance problem?

If you have a (new) range of zeroes in the target stream, the delta for 
it should look like this:

    new-data "\0"
    target-copy -1 <length of range -1>

You'd get two instructions instead the ideal one, but the zeroed range 
is still run-length encoded in practice.

I fail to see what that has to do with sparse files, though. Are you 
implying that Subversion should create sparse files on the client if 
they're supported? If so, that's entirely independent of the deltas.

-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org