Hyrum K. Wright wrote:
> Hyrum K. Wright wrote:
>> C. Michael Pilato wrote:
>>> Hyrum K. Wright wrote:
>>>> Vlad Georgescu wrote:
>>>>> The old code used the revision specified by -r as both a peg rev and an
>>>>> op rev, but now svn_opt_resolve_revisions will set the peg rev to HEAD
>>>>> for all existing externals definitions, which I think is a
>>>>> backward-incompatible change.
>>>> That is correct. There is precedent for doing this, though. We made
>>>> the same change when adding peg revision syntax to commands, such as
>>>> 'svn copy' and 'svn log'.
>>> This line of thought feels incomplete to me.
>> Ah, sorry to be a bit terse. Let me elaborate.
>>
>> My reference comes from implementing peg revision support for 'svn
>> copy'. After doing so, I noticed that some of the tests started
>> breaking, ones that were attempting to resurrect old versions of deleted
>> files. 'svn cp -r 1 deleted_file new_file' failed because new_file
>> wasn't available in HEAD.
>>
>> When I mentioned this on irc, the response was, in not so many words,
>> "the original meaning of -r 1 is broken, people should really be using
>> @1 if they want to refer to something that is different than it is in
>> HEAD." I updated the tests and moved on.
>>
>>> Yes, users can change their behaviors at the command-line to take advantage
>>> of (or otherwise deal with) a new syntax. But they *can't* easily modify
>>> their version history and tweak old svn:externals values such that they
>>> continue to work after an upgrade of their Subversion client. Then again,
>>> one could argue that they'd have equal trouble retroactively fixing
>>> versioned build scripts and such that made use of the pre-peg-rev
>>> command-line syntax.
>> Thanks for pointing that out; I hadn't considered *old* svn:externals
>> properties that may be affected by this change.
>>
>> Adding peg revision support to svn:externals is an important part to
>> maintaining consistency across the Subversion interface, as well as
>> adding the flexibility that peg revisions provide. But if the
>> compatibility ramifications are too large, I'm happy to file this one in
>> the issue tracker for 2.0, and move on.
>>
>>> Is this an apples-to-apples comparison, or is there passion fruit in our midst?
>> I suspect that there is a bit of apple-passion-mango involved. :)
>
> 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
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?
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Feb 28 21:06:23 2007