[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Format bump for 1.8?

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 28 Jun 2012 01:19:51 +0200

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:
>> Historically, whenever we have changed the format, then the working
>> copy is auto-upgraded the first time we (re)wrote the .svn/entries
>> file. The upgrade was invisible and fast, so it Just Happened. At that
>> moment, older versions of Subversion could no longer use the working
>> copy.
>>
>> The 1.7 upgrade was considered too time-consuming and invasive to
>> continue with the auto-upgrade mechanism. We required people to
>> manually upgrade the working copy.
>
> 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.

>> Today, we carry around the working copy's format in one of the wc_db
>> structures. We also have flags for performing upgrades. It should not
>> be too hard for the code to work with multiple formats.

That's good to hear, that it's at least theoretically possible to do this.

>> 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 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.

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?

(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 ...).

-- 
Johan
Received on 2012-06-28 01:20:44 CEST

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.