[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: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 31 Jan 2015 12:58:38 +0100

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 <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
> 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 13:01:29 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.