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@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@peg" if the object was deleted, moved or recreated. Similar to the result of "svn checkout -rHEAD path@peg". Why should svn:externals behave differently here? Greetings, Julian -----Ursprüngliche Nachricht----- Von: Les Mikesell [mailto:lesmikes...@gmail.com] Gesendet: Freitag, 22. Juni 2012 14:55 An: Stephen Butler Cc: Ruhe Julian; Daniel Shahaf; users@subversion.apache.org Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD On Fri, Jun 22, 2012 at 6:19 AM, Stephen Butler <sbut...@elego.de> wrote: > >> -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 > > 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 lesmikes...@gmail.com
