> Branko Čibej <br...@apache.org> writes: > > > capabilities somewhere in the code. In any case, the documentation (and > > the implementation) clearly states we should be seeing client > > capabilities here, so it looks like a bug at first glance.
> It is deliberate: http://svn.haxx.se/dev/archive-2007-11/0347.shtml > The revision in question is now r867730. Thanks Philip for the history/background on this. I reviewed that thread and the commit you mention. It looks like there was a decision-made at that point, that the client-capabilities that a start-commit hook-script should (can) care-about is exactly equal to the list if client-capabilities that the server should care about. The criteria for what client-capabilities the server should care about, and why that list should precisely equal "mergeinfo" is unclear to me, but that is not surprising given my lack of knowledge of the server-internals. The code-change in r867730 seems to hard-wire the set of changes reported to "mergeinfo", and that would require maintenance, which might explain why that is still the set of client-capabilities passed to start-commit, or it might be that all more-recent capabilities, such as inherited-props, are also deemed uninteresting to the server and hence by the logic above, to start-commit also. Is it still considered valid to filter the client-capabilities passed to start-commit? The topic seemed to start with a conversation about separately-reporting client RA/protocol versus client-feature capabilities, but this resulted in the aforementioned "censoring" of the list of capabilities. Shouldn't start-commit be passed everything the client sends, and the hook-script author can decide for themselves what is important (in the context of the hook-script) and what isn't? What start-commit sees and what the server deems important about the client-capabilities seem like two separate topics to me, but I may be misguided in my guess at what the intended scope of start-commit is. Thanks Brett > -- > Philip Martin > WANdisco
