On Wed, Jun 27, 2012 at 7:19 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Tue, Jun 26, 2012 at 10:51 AM, Stefan Sperling <stsp_at_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
Received on 2012-06-28 01:33:25 CEST