Hello Daniel, Besides the fact that there is no good reason why svn:externals does _not_ accept -rHEAD, which is unexpected behavior, since any command does accept -rHEAD, let me explain my use case:
Actually I am trying to track only one specific object (o) per path and I point to it with given peg. But as operating revision I want to have always the most recent revision in my wc. If someone deletes the object (o) I track and creates a new one (o') on the same path, I am not interested in the new object (o'). In this case svn update should tell me that my object (o) does no longer exist on HEAD. So, yes, there is a good reason to expect that @r109 and @HEAD are not ancestrally related. -rHEAD ^/mapping_services/global/testing/full_test/globalresource6.xml@109 => gives me an error on svn up if gr.xml6@109 does no longer exist on HEAD ^/mapping_services/global/testing/full_test/globalresource6.xml (your proposal) => gives me the wrong object I am not interested in Unfortunately you cannot expect the user which is going use our software to fix the problem by hand. We will provide a very limited view to the underlying version control system, though the user will not have the chance to call any svn command at all. I think my use case is not completely remote. I hope I can create an issue for it. Greetings, Julian -----Ursprüngliche Nachricht----- Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Gesendet: Freitag, 22. Juni 2012 01:47 An: Ruhe Julian Cc: users@subversion.apache.org Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD You're asking svn to trace history forward. (from r109 to rHEAD.) In general there will be N places in rHEAD that are related to gr6.xml@109. Is there a reason to expect that ^/mapping_services/global/testing/full_test/globalresource6.xml@HEAD and ^/mapping_services/global/testing/full_test/globalresource6.xml@r109 will at some point not be ancestrally related? If not, you could just drop both -rHEAD and @109 and get the same result.
