On 31.01.2015 11:09, Bert Huijben wrote:
> 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)
Yes, that's what I meant. OK to merge, but some things need fixing
before the release.
> 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.
No, we shouldn't. IMO, adding a 'branch' and 'tag' command will be a
natural outcome of the branch/move work that Julian's been doing; it'll
make sense once the lower layers (API and repository) can take advantage
of the semantic difference between copying, branching and tagging.
> 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 <mailto:brane_at_wandisco.com>
> *Sent:* Saturday, January 31, 2015 10:44 AM
> *To:* dev_at_subversion.apache.org <mailto:dev_at_subversion.apache.org>
> On 28.01.2015 10:54, Stefan Sperling wrote:
> > I'd like to start a vote about merging the pin-externals branch to
> 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.
> -- Brane
Received on 2015-01-31 13:01:29 CET