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

Re: [vote] pin-externals branch to trunk

From: Bert Huijben <bert_at_qqmail.nl>
Date: Sat, 31 Jan 2015 10:09:18 +0000

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…


Bert







From: Branko Čibej
Sent: ‎Saturday‎, ‎January‎ ‎31‎, ‎2015 ‎10‎:‎44‎ ‎AM
To: 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 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.

-- Brane
Received on 2015-01-31 11:20:16 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.