On 07/14/2011 01:16 PM, Philip Martin wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>
>> Another less-obvious one was with the introduction of merge
>> tracking, where the repository format version dictated support (or lack
>> thereof) for a client-visible feature. You might have had an existing 1.4
>> server (no merge tracking), popped up a 1.5 slave when that feature was
>> released, and now the clients are told that the server supports merge
>> tracking when it actually doesn't.
>
> Does that matter? The slave replies to all read requests from its own
> repository, and that does support mergeinfo. Only write requests in a
> commit go through to the master and its repository. Are there any write
> requests that depend on the server's support for mergeinfo?
Correction: It's not strictly true that the slave replies to all read
requests. The slave proxies any read requests aimed at commit transaction
resources to the master -- the only place where the commit transaction lives.
All that said, I don't think we query the mergeinfo of transaction
resources. Maybe you're right and there's no immediate problem here. I
mean, on the master, the svn:mergeinfo property would just look like a
property. I suspect that if you later ran 'svnadmin upgrade' on the master
repository, the internal mergeinfo indexes would be all fouled up, but those
really just aid the performance and accuracy of read requests. Any
post-commit hooks on the master which are dependent on accurate merge
tracking reporting may not behave as expected, either.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-07-14 20:38:34 CEST