> Branko Čibej <brane_at_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.
> Philip Martin
Received on 2015-09-16 03:39:34 CEST