I assume you meant something other than "c" :-P
Agreed. No changing the wc!
I would suggest that we do (a) and (b). And for (a), I'd suggest that
we try an svnversion on PATH, and if that fails (or returns
"unknown"), then try the just-built version.
Option (d) would need to break some abstractions to read older working
copies. The wc-ng model says "can't read that. upgrade." We *could*
create an API specifically for revision_status.c to get the tidbits of
info from older working copies (we have to be able to read them for
upgrade purposes, but we don't plan to expose APIs around those
readers). But I'd rather not do such a special-purpose API, and just
let the sucker print "unknown".
Cheers,
-g
On Thu, Apr 9, 2009 at 18:03, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
> Options:
> a. try to use the installed svnversion before the just-built
> svnversion. If the build dir is a working copy there must be a svn
> installation available, if it's not a wc we can't get the version
> number anyway.
> b. make svnversion print 'unknown' as version number when it can't
> read the wc format.
> c. add a toggle to svnversion to explicitly choose that a wc upgrade
> may be done.
> d. make svnversion independent of the wc upgrade, by making it read
> all older wc versions.
>
> I don't like the idea of read-only tools upgrading the working copy,
> so I prefer option a or c.
>
> Lieven
>
> On Thu, Apr 9, 2009 at 5:16 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> Looking at this failure, it appears (as mentioned below) that we use the
>> just-built svnversion to look at the source tree and include the version
>> number in the output of mod_dav_svn (the little "Powered by Subversion YY
>> (rXXXXX)" tag).
>>
>> I don't know the best way to solve this problem. The naïve (and stupid)
>> approach would be to upgrade the working copy as part of the build process,
>> but that's really a non-option. Any other ideas?
>>
>> -Hyrum
>>
>> On Apr 8, 2009, at 9:49 AM, Greg Stein wrote:
>>
>>> At the end of the build process, we run the just-built svnversion to
>>> gather version info about the source tree. trunk doesn't like 1.6
>>> working copies.
>>>
>>> hwright is looking into the problem now.
>>>
>>> Cheers,
>>> -g
>>>
>>> On Wed, Apr 8, 2009 at 16:29, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
>>>>
>>>> Hm, the mac buildslave uses the system svn client to checkout/update
>>>> the working copy. The working copy shouldn't be touched by the svn
>>>> client that's being built and tested.
>>>>
>>>> I'll have a look tonight.
>>>>
>>>> Lieven
>>>>
>>>> On Wed, Apr 8, 2009 at 2:45 PM, Greg Stein <gstein_at_gmail.com> wrote:
>>>>>
>>>>> There is some weirdness in the new format-detection and upgrade code.
>>>>>
>>>>> I gotta wrap and commit some other code, then I'll get this fixed up.
>>>>> Or work with hwright when he's back online. Whichever comes first.
>>>>>
>>>>> Cheers,
>>>>> -g
>>>>>
>>>>> On Wed, Apr 8, 2009 at 11:13, Bert Huijben <rhuijben_at_sharpsvn.net>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> The mac buildbot is reporting (build phase):
>>>>>>
>>>>>> svn: Working copy format is to old; run 'svn cleanup' to upgrade
>>>>>>
>>>>>>
>>>>>>
>>>>>> It looks like it uses a (broken) trunk build for some local subversion
>>>>>> operations?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bert
>>>>>
>>>>> ------------------------------------------------------
>>>>>
>>>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1595977
>>>>>
>>>>
>>
>>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1616211
Received on 2009-04-09 22:23:10 CEST