On Fri, May 16, 2025 at 6:54 AM Branko Čibej <br...@apache.org> wrote:
> On 15. 5. 25 18:30, rin...@apache.org wrote: > > Author: rinrab > Date: Thu May 15 16:30:35 2025 > New Revision: 1925565 > > > [...] > > --- subversion/trunk/subversion/include/svn_client.h (original) > +++ subversion/trunk/subversion/include/svn_client.h Thu May 15 16:30:35 2025 > @@ -7771,6 +7771,28 @@ svn_client_patch(const char *patch_abspa > svn_client_ctx_t *ctx, > apr_pool_t *scratch_pool); > > +/** > + * Similar to svn_client_patch(), but the patch is read from a file handle, > + * described in @a patch_file. > + * > + * In feature versions, this function may be used to apply a patch directly > + * from an svn_stream_t. > > > "feature"? Or did you mean "future"? > Oh, my bad. Fixed in r1925585. > Anyway, I'd leave out this paragraph. Or use svn_stream_t now, because > you'd have to bump the function version in any case. > > Sure I understand why you wouldn't want to spend time on that, you'd have > to change the implementation of the patch parser, too. That could be ... > quite a lot of work. > > Do you mind if I give it a go? I rather like the idea of using generic > streams for this. > Yeah, this requires to go through the whole parser and make sure everything still works right, while also maintaining compatibility with file api. However, nothing really complicated is needed. This also will make the patch implementation more straightforward, due to the stream abstraction. In other words, this will be helpful, and if you wish to try it out -- I'm fully +1 for this. I'll be happy to see and review it as needed! > -- Brane > -- Timofei Zhakov
