On Tue, 13 Feb 2007, Kamesh Jayachandran wrote:
> Blair wrote:
> ...
> >I presume there are new APIs that the svn HTTP client is using to send
> >to the server to update the metadata? Or this is just a property only
> >change?
>
> It is just a property change.
When necessary, the client uses a new merge info retrieval API to look
up merge info stored in the repository which may or may not be
available locally (if no merge info is set on a path, it's inheritted
from parent paths).
For ra_svn, the client uses the available capabilities detection
facilities to determine whether the repository supports this API.
For ra_dav and ra_serf, the client always tries to retrieve the merge
info, assuming there's no merge info if the repository responds with
HTTP_NOT_IMPLEMENTED (501).
For ra_local, this is obviously a non-issue.
> >Could we not have the client always make a call to some new API that
> >would indicate to mod_dav_svn that even if there's no merge metadata
> >to send, that the client would have sent it if there was info to send?
> >
> >The server could have a bit checked when it saw this call, indicating
> >that the client is merge metadata aware.
>
> Not sure how it would help.
> Let us say whenever a merge happens we mandate some indicator_API to be
> called to ensure that Caller is a 1.5.x client.
> Server is totally incapable to distinguish a commit being a result of
> merge+commit or adhoc change + commit.
>
> If it is merge+commit 1.5.x client would have called indicator_API that
> would give a clue of 'merge+commit'. But how can we differentiate from
> 'merge+commit' by <1.5.x clients and any other commit from any client.
- application/pgp-signature attachment: stored
Received on Wed Feb 14 01:26:10 2007