Yes, in some manner, they will complain :)
David Glasser wrote:
> So the answer is roughly "older clients will complain on checkout"?
>
> --dave
>
> On 10/18/07, Blair Zajac <blair@orcaware.com> wrote:
>> We have the same issue with the new peg revision format being unparsable by
>> older clients. I haven't tried all combinations, but with absolute URLs and the
>> new external format, the client will complain about it.
>>
>> We will probably run into problems with relative URLs since the new code takes
>>
>> relative_path relative_path
>>
>> as
>>
>> relative_url relative_path
>>
>> while old code will take it to be
>>
>> relative_path relative_url
>>
>> but this will also break.
>>
>> I just think people will need to watch out for using new style externals.
>>
>> Blair
>>
>> David Glasser wrote:
>>> Blair, reading me makes me wonder what happens what happens if you use
>>> the new syntax and try to check out with an old client. Is that
>>> documented somewhere?
>>>
>>> --dave
>>>
>>> On 10/18/07, blair@tigris.org <blair@tigris.org> wrote:
>>>> Author: blair
>>>> Date: Thu Oct 18 12:09:58 2007
>>>> New Revision: 27281
>>>>
>>>> Log:
>>>> * subversion/svn/main.c
>>>> (svn_cl__cmd_table):
>>>> Update the description on svn:externals to document the new
>>>> relative externals feature.
>>>>
>>>>
>>>> Modified:
>>>> trunk/subversion/svn/main.c
>>>>
>>>> Modified: trunk/subversion/svn/main.c
>>>> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/svn/main.c?pathrev=27281&r1=27280&r2=27281
>>>> ==============================================================================
>>>> --- trunk/subversion/svn/main.c (original)
>>>> +++ trunk/subversion/svn/main.c Thu Oct 18 12:09:58 2007
>>>> @@ -697,9 +697,25 @@
>>>> " treated as text. Anything else is treated as binary.\n"
>>>> " svn:externals - A newline separated list of module specifiers,\n"
>>>> " each of which consists of a relative directory path, optional\n"
>>>> - " revision flags, and an URL. For example\n"
>>>> + " revision flags and an URL. The ordering of the three elements\n"
>>>> + " implements different behavior. Subversion 1.4 and earler only\n"
>>>> + " support the following formats and the URLs cannot have peg\n"
>>>> + " revisions:\n"
>>>> " foo http://example.com/repos/zig\n"
>>>> " foo/bar -r 1234 http://example.com/repos/zag\n"
>>>> + " Subversion 1.5 and greater support the above formats and the\n"
>>>> + " following formats where the URLs may have peg revisions:\n"
>>>> + " http://example.com/repos/zig foo\n"
>>>> + " -r 1234 http://example.com/repos/zig foo/bar\n"
>>>> + " Relative URLs are supported in Subversion 1.5 and greater for\n"
>>>> + " all above formats and are indicated by starting the URL with one\n"
>>>> + " of the following strings\n"
>>>> + " ../ to the parent directory of the extracted external\n"
>>>> + " ^/ to the repository root\n"
>>>> + " // to the scheme\n"
>>>> + " / to the server root\n"
>>>> + " The ambiguous format 'relative_path relative_path' is taken as\n"
>>>> + " 'relative_url relative_path' with peg revision support.\n"
>>>> " svn:needs-lock - If present, indicates that the file should be locked\n"
>>>> " before it is modified. Makes the working copy file read-only\n"
>>>> " when it is not locked. Use 'svn propdel svn:needs-lock PATH...'\n"
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
>>>> For additional commands, e-mail: svn-help@subversion.tigris.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 19 01:21:40 2007