On Jun 22, 2012, at 10:32 , Ruhe Julian wrote: > 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,
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. > 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. There was a detailed description of the problem on this list a year ago. http://svn.haxx.se/users/archive-2011-03/0262.shtml This is similar to a feature suggestion for a '--'svn log': to show the revisions at a given URL without following copy-operations. http://svn.haxx.se/users/archive-2009-12/0219.shtml 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? Should the search stop at the first deletion or keep going? What if the next item at that URL has a different type (dir/file/symlink)? You might want the search to stop, another user might want it to continue through the history of the item with the different type. The options seem to be multiplying. The 'svn update' code is already pretty complicated (handling mixed revisions, '--depth' exclusions, tree conflicts, etc, etc) without adding a big "search for the right target version" feature to it. > > -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. Regards, Steve > > 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. -- Stephen Butler Consultant elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Building 12 13355 Berlin, Germany tel: +49 30 2345 8696 | mobile: +49 163 25 45 015 fax: +49 30 2345 8695 | http://www.elego.de Geschäftsführer: Olaf Wagner, Michael Diers Sitz der Gesellschaft: Berlin Handelsregister: Amtsgericht Charlottenburg HRB 77719
