You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2011/05/16 16:49:52 UTC
Re: [RFC] let old svn's error properly in some 'svn1.7 checkout &&
svn1.6 status' scenarios
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.
> > % 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
we should update the FAQ answer given there.
> > 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.
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.
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).
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
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.
- Julian
Re: [RFC] let old svn's error properly in some 'svn1.7 checkout &&
svn1.6 status' scenarios
Posted by Daniel Shahaf <da...@elego.de>.
r1104192, with thanks to Bert for pointing out the easiest place to
add the upgrade codepath in.
Re: [RFC] let old svn's error properly in some 'svn1.7 checkout &&
svn1.6 status' scenarios
Posted by Daniel Shahaf <da...@elego.de>.
Julian Foad wrote on Mon, May 16, 2011 at 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:
> > > 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.
>
r1104049.
> > > > > 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.
(still working on it)
Re: [RFC] let old svn's error properly in some 'svn1.7 checkout &&
svn1.6 status' scenarios
Posted by Julian Foad <ju...@wandisco.com>.
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
Re: [RFC] let old svn's error properly in some 'svn1.7 checkout &&
svn1.6 status' scenarios
Posted by Daniel Shahaf <da...@elego.de>.
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
>
>