On Fri, Sep 05, 2014 at 01:00:09PM +0200, Bert Huijben wrote:
> Why do we need a tmp file in the api? GUI clients in general don't need/want a temp file.
>
> This looks like you are trying to implement 'svn' behavior in the svn_client layer.
>
> I don't see why the tmp_file can't be passed via the baton... if needed by wrapping one baton in another at some helper function layer.
>
> The documentation you added doesn't document tmp_file and the documentation for log_message_templates doesn't explain what it does.
The temp file already existed in svn_client_get_commit_log3_t.
I didn't add this parameter and I didn't add documentation for it.
> E.g. If I'm committing changes to "C:\inetpub\wwwroot\some-file.aspx" and "F:\projects\libraries\some-file.c" what can I expect here?
>
> The nodes are certainly not in the same working copy, but can be from the same repository and as such committed to a single revision. What keys can I expect in log_message_templates. (Which can't be const, as there are no apis that can consume const apr_hash_t * :( )... and what values?
What to do about multi-WC commits is a good question.
I'll think about that.
> Currently I would read the documentation as const char * "<template>" mapping to 'commit items'... But an apr_hash_t has a one to one relation, so it could only point to one.
cmpilato used a mapping from log template to a list of commit items.
I'm considering alternatives right now but wanted to change the way
the templates are passed to the API consumer first.
Do you agree that passing templates to the callback is better?
This commit didn't really want to change much more than that.
Received on 2014-09-05 13:48:59 CEST