[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Peg revision support for svn:externals

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-02-20 23:13:16 CET

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. :)


Received on Tue Feb 20 23:13:33 2007

This is an archived mail posted to the Subversion Dev mailing list.