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.
Thoughts?
-Hyrum
Received on Wed Feb 28 17:31:02 2007