[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: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 16 May 2011 17:37:28 +0100

On Mon, 2011-05-16 at 17:34 +0200, Daniel Shahaf wrote:
> 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.

Thanks.

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

That sounds fine.

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

Sounds good to me.

- Julian
Received on 2011-05-16 18:38:02 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.