On 7/13/2010 8:35 AM, Stefan Sperling wrote:
When the code has beem moved around. There's a description at
http://svnbook.red-bean.com/en/1.1/ch07s03.html which helps explain
it.
Mind you, I think if you're doing this kind of drilling back you're
begging or pain.
Yes I understand the situation where you would have to use p...@rev
to get something at all (because history doesn't lead there). What
I don't understand is when you would ever be wrong if you used that
all the time instead of -r rev. Which leads to the related
question as to why that syntax isn't the default for commands. Is
it less efficient than following history backwards?
There is no difference.
In the "-r rev" syntax, the rev is interpreted as a peg revision.
See
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/props.c?revision=961970&view=markup
lines 3026 to 3092, inside function svn_wc_parse_externals_description3().
Revisions parsed from either syntax set the same variable (item->peg_revision).
The new syntax is simply more convenient because the order of URL and path
is consistent with svn checkout.
I meant it as a more general question, not just in the context of
externals. Is there some reason not to use the p...@rev style for every
command or document that as the preferred method? There are some
situations where it is easier to construct, like a parametrized build in
Hudson, for example.
--
Les Mikesell
lesmikes...@gmail.com
