On Mon, Jun 25, 2012 at 8:07 PM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Ruhe Julian [mailto:jr...@axway.com] >> Sent: vrijdag 22 juni 2012 14:57 >> To: Stephen Butler >> Cc: Daniel Shahaf; users@subversion.apache.org >> Subject: AW: Issue: svn:externals syntax does not accept -rHEAD >> >> Hello Daniel, >> >> >The update command accepts -rHEAD, but not necessarily -rHEAD plus peg >> revision. HEAD is a keyword for "latest in the repository", not "latest > in the >> history of URL@REV". If an item has been deleted, it's no longer part of > the >> >HEAD, as you've seen. >> >> That is not the point. I did not state this. In the svnbook in the chapter >> regarding peg revisions you can find a clear statement that recreated > objects >> on the same path are not the same things. That's why it's perfectly valid > to >> ask "give me the HEAD version of an object existing @peg." And the result >> should be either >> a) if the same object exist on HEAD on that path => give that object >> b) if no object exists on HEAD that path => give me an error >> c) if another object (recreated) after deletion exists on HEAD that path > => >> give me an error >> >> This is how svn checkout (svn co -rHEAD path@peg) works. I do not >> understand why I should not be allowed to advise svn:externals to do the >> same. Just to follow the specification of operating revision and peg > revsions. >> >> > It sounds like you want Subversion to search for the latest revision in > the >> history of URL@REV. What if that item was deleted and later restored? >> >> No. Not at all. Forward history of an object is another topic. >> >> >> >> -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. >> >> Wrong object? I just said that two objects on the same path are different > to >> me. And I actually just want an answer on question "Does the file external >> path@peg exist on HEAD?". Answer: "Yes" or "No" or technically "object >> returned" or "error". >> >> I cannot even answer this question with the given syntax. What is so > difficult >> to allow -rHEAD on svn:externals? > > We don't have forward history searching in Subversions filesystems. So > allowing this option requires extending the filesystem layer. > > And given that usually -r follows copies, there could be multiple answers, > which makes designing this option in the filesystem hard and the result > inconclusive.
Bert, As I mentioned in my previous post [1] in this thread, the OP does *not* want it to follow moves or copies. He wants the same behavior as checkout or update, which is that this is possible (but errors out if there is a move/copy). I.e. (see [1]): 'svn checkout -r100 $URL@50' works just fine, as long as $URL@50 is the same node as $URL@100. Since checkout and update can already do this kind of stuff, it seems logical that externals should be able to do the same. [1] http://svn.haxx.se/users/archive-2012-06/0264.shtml -- Johan
