Point. Meanwhile I think I somehow lost the summary of the log
message, leaving just the per-function entries. How about:
[[[
Allow pre-lock hook to be able to specify lock-token to be used with
stdout output.
**** NOTE ****
This will cause existing pre-lock hook that prints to stdout to be incompatible
with this change, where the output were previously discarded.
This should be mentioned in the release notes.
* subversion/libsvn_repos/fs-wrap.c
(svn_repos_fs_lock): allow returned new_token from pre-lock hook.
* subversion/libsvn_repos/repos.h
(svn_repos__hooks_pre_lock): now has additional returned value for token.
* subversion/libsvn_repos/hooks.c
(run_hook_cmd): allow stdout of hook to be captured and returned.
Update all callers.
(svn_repos__hooks_pre_lock): get token from run_hook_cmd.
* subversion/libsvn_repos/repos.c: Document the pre-lock feature for
token from stdout.
]]]
Cheers,
CLK
2008/8/8 C. Michael Pilato <cmpilato_at_collab.net>:
> This might be considered quite tangential, but I very much feel that the log
> message for the commit of this feature should call out clearly (perhaps with
> "***NOTE***" or something) that this changes the contract for existing
> pre-lock hooks which might be spewing stdout today. We'll want to
> release-note this as a compatibility concern. Or, we can go ahead and begin
> the svn_1.6_releasenotes.html document with at least something about this
> scribbled therein.
>
>
> Chia-liang Kao wrote:
>>
>> Alright, here's the one with all callers updated.
>>
>> [[[
>> * subversion/libsvn_repos/fs-wrap.c
>> (svn_repos_fs_lock): allow returned new_token from pre-lock hook.
>>
>> * subversion/libsvn_repos/repos.h
>> (svn_repos__hooks_pre_lock): now has additional returned value for token.
>>
>> * subversion/libsvn_repos/hooks.c
>> (run_hook_cmd): allow stdout of hook to be captured and returned.
>> Update all callers.
>> (svn_repos__hooks_pre_lock): get token from run_hook_cmd.
>>
>> * subversion/libsvn_repos/repos.c: Document the pre-lock feature for
>> token from stdout.
>> ]]]
>>
>>
>> 2008/8/7 Karl Fogel <kfogel_at_red-bean.com>:
>>>
>>> "Chia-liang Kao" <clkao_at_clkao.org> writes:
>>>>
>>>> 2008/8/3 Arfrever Frehtes Taifersar Arahesis <arfrever.fta_at_gmail.com>:
>>>>>
>>>>> This is private function so no compatibility should be required.
>>>>
>>>> I guess it's mostly because i have another patch at the same time and
>>>> i didn't want to make them interdependent. Can I un-revision the
>>>> private function after they are both approved?
>>>
>>> I confess, I completely didn't understand this explanation... :-) Help?
>>> (Or just post a new version without the needless private API rev?)
>>>
>>> Thanks,
>>> -K
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-08 18:37:54 CEST