On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling <s...@elego.de> wrote: >> On Mon, Jun 25, 2012 at 07:51:59PM -0400, Greg Stein wrote: >... >> I would prefer to by default keep working copy upgrades manual from now on. > > +1, let's please keep it an explicit action by the user.
Not sure about that. The user will type 'svn move' and not get the benefits. All the docs will say it *should* work, but it doesn't. Oh... right. The user didn't bother to upgrade the working copy. Gee. Too bad. That's rather confusing. What other features won't work? >... >>> However: we don't have a good concept of "read-only vs read-write" >>> operations at the wc_db level, like we used to have with the entries >>> file. As soon as we touch a working copy (eg. "svn info" or "svn >>> status"), then we would likely perform the auto-upgrade. We might need >>> some decent tooling to go back to the "only upgrade when writing" >>> model. For example, maybe when an administrative lock is constructed, >>> then we check for an old format and perform the auto-upgrade before >>> continuing the (modifying) operation. > > Ok, but if we keep upgrade an explicit action, this won't be a > problem, right? No need to determine whether to auto-upgrade or not. If we don't auto-upgrade... sure. But I think we should continue to auto-upgrade in the general case. We did it for years without horrible user feedback (afaik). > If the code could work with older working copy formats, then there's > also no immediate need for the user to upgrade, unless he wants to > take advantage of newer features. Confusing. And hidden. And yet another variable in the user's config/environment that will throw off our ability to support them. "Wait. You didn't upgrade your working copy? Go away. You're pissing me off." > I think the question is: is there a willingness in the community to > take on the additional burden of making the code flexible enough, so > it can work with multiple working copy formats? Making some code paths > conditional on the working copy version in one way or another? Some. Sure. > (As I noted before, svnkit has this special ability: the latest > version (1.7.5) can work with working copies in 1.3, 1.4, 1.5, 1.6 and > 1.7 formats, without upgrading them. It's effectively a backwards > compatible client. That makes svnkit a very interesting svn client in > some environments / situations. I just wish svn itself could do the > same ...). There was absolutely no way to get the wc-ng benefits and still write to the old .svn/entries. The entire working copy library was rebuilt. If we didn't not have a separate client vs wc API, then it *may* have been possible to support older formats more easily. When you're only talking about client APIs that do $FOO, then the actual storage format becomes much less important. You just want to munge it from one state to another. But we have an independent working copy library that allows a lot of detailed operations. Supporting those across multiple formats was simply not a workable answer. Cheers, -g
