Hyrum K. Wright wrote:
> Michael Sinz wrote:
>> On 2/28/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>>> Hyrum K. Wright wrote:
>>>> Does anybody have any other comments on the backwards compatibility
>>>> implications here? I'm leaning toward the "this is just a little too
>>>> much breakage" side of the things (though I could be convinced
>>> otherwise
>>>> :), and I'm planning on putting this in the issue tracker for 2.0.
>>> What if we did the following (WARNING, I'm in a weird mood):
>>>
>>> I almost always mess up the setting of the svn:externals property the
>>> first
>>> time because the order of the "arguments"...
>>>
>>> target-dir [-rM] http://.../path/to/checkout
>>>
>>> ...is exactly the opposite of the typical checkout command-line
>>> syntax. So
>>> what if we declared a new version of the syntax, that looked like this:
>>>
>>> http://.../path/to/checkout[@PEG-REV] [-rM] target-dir
>>>
>>> (or maybe)
>>>
>>> [-rM] http://.../path/to/checkout[@PEG-REV] target-dir
>> I like this one as it is obvious as to it being different (options first)
>> plus it very much matches the "usual" svn command line order.
>>
>> Anyway, the point is that a) you'd be able to detect the new format using
>>> svn_path_is_url() checks on the arguments, and b) now folks can verify
>>> their
>>> externals definitions by tacking them onto the end of 'svn checkout' at
>>> the
>>> command-line.
>>>
>>> Thoughts? Tomatoes?
>>
>> Actually, no tomatoes but a nice, large apple :-) To me, at least, this
>> would allow for backwards compatibility with older externals. The only
>> issue left is what this does to older clients. If it fails "cleanly" (no
>> pollution of the WC) then that is reasonable. I guess that it requires
>> some
>> testing to validate that.
>
> Thanks for the comments!
>
> My 1.3.2 client errors out cleanly on both of CMike's suggestions, but
> in different ways. Using the first syntax, I get an error when
> updating, but when using the second syntax, I get an error when
> attempting to set the svn:external property.
>
> I like the second error mode better, because it prevents somebody from
> setting a bogus property that their client can't understand. They may
> still pull one down as part of an update from some other client (which I
> haven't tested), but at least it eliminates their ability to set it locally.
>
> Although, I prefer the first suggestion syntactically, it leaves junk
> laying around in the WC after it fails. I'm going to go ahead and
> implement the second version.
Well, after playing around with that, and running into a few deadends,
another thought occurred to me. Instead of inventing a new syntax, why
don't we just set the peg revision equal to the provided revision if no
peg revision exists, and apply the normal resolution rules when a peg
revision is given? This would maintain backward compatibility, without
having to introduce another syntax.
-Hyrum
Received on Thu Mar 8 03:46:57 2007