On 09/24/2012 12:23 PM, Philip Martin wrote:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>
>> Is it just a bug in the test script, whereby it uses the just-compiled
>> svn instead of /usr/bin/svn?
>>
>> C. Michael Pilato wrote on Mon, Sep 24, 2012 at 11:32:03 -0400:
>>> Aaaaand auto-upgrade strikes again. #hatethisnonfeature
>>>
>>> On 09/23/2012 08:33 PM, neels_at_apache.org wrote:
>>>> subversion/libsvn_wc/revision_status.c:64: (apr_err=155021)
>>>> subversion/libsvn_wc/wc_db.c:12198: (apr_err=155021)
>>>> subversion/libsvn_wc/wc_db_wcroot.c:609: (apr_err=155021)
>>>> subversion/libsvn_wc/wc_db_wcroot.c:266: (apr_err=155021)
>>>> svn: E155021: This client is too old to work with the working copy at
>>>> '/home/neels/pat/trunk/src' (format 30).
>>>> You need to get a newer Subversion client. For more details, see
>>>> http://subversion.apache.org/faq.html#working-copy-format-change
>>>
>>> [...]
>
> The code that locates the working copy root will upgrade an unrelated
> working copy if it has to examine it.
>
> svn1.7 co URL wc1.7
> svn1.8 co URL wc/nested
>
> causes wc1.7 to be upgraded.
That's correct.
And Philip, I see this as really two issues:
1. we auto-upgrade working copies (at all)
2. we auto-upgrade working copies that are arguably not the true targets of
an operation.
I can live with the first problem if I must. It's the second that's the
more egregious of the two, in my book. So yes, I think it makes (as you
suggested elsethread) to add a 'read-only' mode to the WCDB, and to use that
mode in the initial exploratory phases of a checkout operation. Maybe we
provide a way to upgrade that to read/write programmatically rather than
closing and re-opening the DB ... no opinion there. Whatever makes the most
sense.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-09-24 19:51:13 CEST