subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: [vote] pin-externals branch to trunk
Date Sat, 31 Jan 2015 11:58:38 GMT
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…
> Bert
> *From:* Branko Čibej <>
> *Sent:* ‎Saturday‎, ‎January‎ ‎31‎, ‎2015 ‎10‎:‎44‎ ‎AM
> *To:* <>
> 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

View raw message