[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge tracking: rejecting commits from svn clients < 1.5

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-02-14 01:25:47 CET

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

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

This is an archived mail posted to the Subversion Dev mailing list.