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

Re: [RFC] let old svn's error properly in some 'svn1.7 checkout && svn1.6 status' scenarios

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Mon, 16 May 2011 17:34:35 +0200

Julian Foad wrote on Mon, May 16, 2011 at 15:49:52 +0100:
> Daniel Shahaf wrote:
> > Daniel Shahaf wrote on Mon, May 16, 2011 at 15:36:25 +0200:
> > > [[[
> > > % wc-format.py
> > > .: 11
> >
> > It said '28' originally.
> >
> > > % svn --version -q
> > > 1.5.1
> > > % svn st -q
>
> When I try with 1.5.9 and 1.6.16, they say "svn: warning: '.' is not a
> working copy" which is different but is still misleading.
>

Yes, I copied the wrong part of my shell session.

> > > % echo 11 > .svn/format
> > > % echo 11 > .svn/entries
> > > % svn st -q
> > > svn: This client is too old to work with working copy '.'. You need
> > > to get a newer Subversion client, or to downgrade this working copy.
> > > See http://subversion.tigris.org/faq.html#working-copy-format-change
>
> The URL is now
> <http://subversion.apache.org/faq.html#working-copy-format-change> and

Fixed on trunk.

> we should update the FAQ answer given there.
>

How? To mention that 1.7 doesn't autoupgrade and doesn't provide
a downgrade script; anything else?

> > > for details.
> > > zsh: exit 1 svn st -q
> > > %
> > > ]]]
> > >
> > > So, RFC:
> > >
> > > * wc-ng working copies shall contain an "entries" file (and/or
> > > a "format" file) containing the text "11\n", inside all .svn
> > > folders they have (if any).
>
> Should be SVN_WC__VERSION (curently 28), not 11.
>

From IRC:

18:20:39 <@julianf> Curious: why on earth would we not want to provide the correct value?
18:21:38 <@Bert> julianf: We would have to maintain it later
18:21:50 <@danielsh> julianf: because we'd have to create/maintain it at the right value,
18:21:52 <@Bert> (not sure if it is a good reason, but it is a reason)
18:21:55 <@danielsh> and what would need it?
18:21:57 <@julianf> OK
18:22:01 <@danielsh> wc1 clients need ">10"
18:22:05 <@danielsh> wc-ng clients use sqlite
18:22:18 <@danielsh> wc-ng-ng clients read "11" as an indication of "this is sqlite backed working copy"

Julian/all, I'll assume "11" is okay if I don't hear otherwise.

> When I try with just a 'format' file it doesn't work. It has to have
> the 'entries' file (as well or instead) to produce the useful
> diagnostic.
>

I don't remember which (or both) of them do old clients look for.
Having both of them is safe though.

> This only helps when the target of "svn st" is the WC root folder
> (except in some cases it works for an immediate child of the root).
>

True.

> Also I would guess there are some other tools (such as Subversion
> plug-ins for IDEs) that would give a more helpful diagnostic if they
> find a WC version number there. I wonder if such tools would
>

> 18:13:12 <@julianf> I meant, "wonder if such tools would like to find a 'format' file, so we ought
> to provide both 'entries' and 'format'."

I see no harm in providing both files. As to old tools that request our
format number via the API, we'll have our API's implemented (the
internal API's too) by looking in wc.db.

> Given all that, and despite only working for the WC root, I think that
> is a useful enough result to be worth doing. I can't think of any
> practical objection to having these one or two extra files per WC if it
> helps smooth the transition for users.
>

Thanks. Working on a patch...

(I'll create a workqueue 'file-install-string' operation for the
svn_wc_upgrade() use case, hence the delay)

> - Julian
>
>
Received on 2011-05-16 17:35:17 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.