I'd like to continue this discussion a bit more, as there are still
some things lingering here ...
On Thu, Jun 28, 2012 at 1:32 AM, Greg Stein <gstein_at_gmail.com> wrote:
> 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?
Yes, I agree we'd have to make it clear in our docs that feature X
depends on working copy format Y. That's an additional effort, yes.
But for the book or the FAQ it's not a lot different from phrases
where they now say: "If you've got Subversion 1.7 or higher, you'll
get ...". Then they'll have to say "If your working copy format is 1.8
or higher, you'll get ...".
For our commandline help output it's probably a bit more difficult:
we'll need to find a concise and elegant way to annotate certain
descriptions in the help output as "only for wc format >= x.y".
Some things that are also probably needed:
- Mention working copy format/version in output of 'svn info' (like we
also give 'Working Copy Root Path' since 1.7).
- Maybe have an explicit subcommand that just reports the wc format
(nice for scripts, if they want to do things conditional on the wc
format -- no need to parse it out of 'info' output). Alternatively, if
explosion of subcommands is a concern, I envisage options for the
'info' command that only give one particular piece of info (or
something like that ... a topic for another thread).
>>...
>>>> 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).
As I said elsethread, most end-users I know consider the "manual
upgrade" in 1.7 a clear improvement over auto-upgrading. It makes the
entire process less scary. It avoids accidents like the scenario I
mentioned, where the user has 3 svn clients (a commandline client, a
GUI tool, and an IDE plugin), which all have their own release cycles.
In that situation, an auto-upgrade by one of the three, while another
can't be upgraded immediatly, can wreak havoc. It's much better to
error out with 'working copy format too old, run svn upgrade'.
Also, as I said, an auto-upgrade needs at least:
- To be reversible (need downgrade feature or script).
- To be fast, and O(1) (consider 1,000,000 nodes WCs).
Now, there is another use case: a build server with 1000 working
copies, and a single svn client. In that case, a fast auto-upgrade is
nice, otherwise it's hard to upgrade the svn client (need to manually
upgrade 1000 working copies). But OTOH, if svn 1.8 would have a
1.7-compat mode, that chicken-and-egg problem would also go away
nicely: upgrade the svn client to 1.8, everything keeps working, and
those 1000 working copies can be upgraded whenever you like.
>> 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."
Agreed, it's another variable to consider when reporting problems and
such. Still, I think most users would appreciate the additional
flexibillity of backwards compatibility with older wc formats.
Of course we should try our best to educate users about this, and to
give them enough information. Like extending the feature compatibility
table in the release notes with a "Minimum working copy format"
column.
Maybe we should ask around on the users-list to get a feel for what
most users think/want.
>> 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.
Just to be clear: I totally understand that this was nearly impossible
to do for 1.7. But I'm only looking at the future here :-). Can we do
better with 1.8 and beyond?
Also, I'm not suggesting that we support new-in-1.8 semantics with a
1.7-WC. Just that the 1.8 client can support 1.7-semantics with a
1.7-WC. I'm asking if it would be possible that a 1.8 client can run
in 1.7-compat mode if it runs on a 1.7-WC. That's effectively what
svnkit and maybe other clients do (AFAIK, they could just be packaging
different clients in one package, and have some kind of dispatch /
polymorphism /... in place that delegates to the correct client
depending on the wc-version).
--
Johan
Received on 2012-07-11 15:51:53 CEST