AW: Issue: svn:externals syntax does not accept -rHEAD

Hi Les,

thank you for your answer. I think I have to explain my use case a little more detailed. First, we are not talking about source code. Users will not be software developers.

Ok, we have defined an area in the repo where "global objects" are stored. Those can be addressed by "projects" using svn:externals. By specification the lifetime of a global objects ends, when it is deleted or moved. The default and normal way to address global objects is by path and fixed revision. In rare cases some of them should be addressed not by a fixed revision but by "always the most recent version". This is what I cannot achieve. I cannot address it by path_at_HEAD because I could get a recreated object after deletions. But this is the wrong object to me. I want an error on my request "-rHEAD path_at_peg" if the object was deleted, moved or recreated. Similar to the result of "svn checkout -rHEAD path_at_peg". Why should svn:externals behave differently here?

Greetings,
Julian
 
-----Ursprüngliche Nachricht-----
Von: Les Mikesell [mailto:lesmikesell_at_gmail.com]
Gesendet: Freitag, 22. Juni 2012 14:55
An: Stephen Butler
Cc: Ruhe Julian; Daniel Shahaf; users_at_subversion.apache.org
Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD

On Fri, Jun 22, 2012 at 6:19 AM, Stephen Butler <sbutler_at_elego.de> wrote:
>
>> -rHEAD
>> ^/mapping_services/global/testing/full_test/globalresource6.xml_at_109
>> => gives me an error on svn up if gr.xml6_at_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
>
> Who put the wrong object there?  If you can solve that organizational
> problem, the technical problem outlined above will no longer be
> relevant, and your Subversion usage will be much simpler and more robust.

I think the usual approach would be to copy to a branch at a point before you expect disruptive operations like deleting/replacing an object to happen. That is, if you branched at your rev 109 example, work on that branch could continue on its own path while the trunk
diverges in its own way. Besides giving the HEAD you are trying to
find a natural place to live, the branch also lets you give it a more
human-friendly name for the external reference. Note that you can
even wait until after the disruptive change happens and copy the
branch from an earlier rev if the changes are not predictable. Also,
when you want to absolutely nail down the referenced external revision you can copy to a tag which, by convention, has no further commits.
Subversion handles these copies efficiently and they are much easier to follow than deleting/replacing objects in the same path (both for subversion and the people using the repository).

--
  Les Mikesell
     lesmikesell_at_gmail.com