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.
-Hyrum
Received on Wed Feb 28 22:59:42 2007