Michael Sinz wrote:
> On 2/28/07, C. Michael Pilato <firstname.lastname@example.org> 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
>> > :), 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
>> 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
>> externals definitions by tacking them onto the end of 'svn checkout' at
>> 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
> 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.
Received on Wed Feb 28 22:59:42 2007