I’ll look into reducing the number of sessions after merging. I don’t think this should really hold back the merging of the branch. (1.8 does the same thing in many cases, while we still call that the released/supported version)
I’m pretty sure we can reduce the number of sessions before 1.9.0 in a simple patch though.
At the api level I don’t think we should add more and more knobs to svn_client_copyX for very specific branch scenarios. I think we should add a different command/function if we want to add more branching specific operations. But I’m not sure if we should really delay 1.9.0 on that.
A WC->WC copy is something that should happen fast and client side only (without outside causes that might break it or cause a dozen possible interactive prompts which just break scripts that assume a copy ‘works’, like it did in 1.0-1.8), while branching/committing is just a different story…
From: Branko Čibej
Sent: Saturday, January 31, 2015 10:44 AM
On 28.01.2015 10:54, Stefan Sperling wrote:
> I'd like to start a vote about merging the pin-externals branch to trunk.
I think this is ready to be merged to trunk, but there are two
outstanding issues that really need to be addressed before we release:
* When the source of the copy is the repository, the current
implementation can potentially open and close a zillion RA sessions.
It does not even attempt to detect if they're sessions to the same
repository, and consequently does not reuse sessions. A lot of work
has been spent in reducing the number of RA sessions opened during
an operation, so this is really unacceptable.
* When the target is the working copy, the current implementation
overrides the ignore-externals flag during the copy until the
externals are pinned. However, no attempt is made to remember the
original value of this flag. Also, I think there's a fundamental
problem with the approach to pinning when the WC is the target: if
the copy succeeds, but pinning the externals fails for whatever
reason -- even a cancellation -- the working copy will be in an
inconsistent state. IMO, the code should queue up WC work items for
the actual pinning, so that the pinning can be rolled forward (or
reverted) completely, not left in a half-baked state.
Received on 2015-01-31 11:20:16 CET