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. Agreed. > 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:br...@wandisco.com> > *Sent:* Saturday, January 31, 2015 10:44 AM > *To:* dev@subversion.apache.org <mailto:dev@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 >
