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

Hello Johan,

Yes, you understood my request correctly. I will create an issue today. Regarding the implementation a simple, automatic replacement of "-rHEAD path_at_peg" by "-r{revision of HEAD} path_at_peg" on each access should do the job perfectly (plus parser modification of course).

Thank you all for the discussion.

Greetings,
Julian

-----Ursprüngliche Nachricht-----
Von: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
Gesendet: Montag, 25. Juni 2012 20:54
An: Bert Huijben
Cc: Ruhe Julian; Stephen Butler; Daniel Shahaf; users_at_subversion.apache.org
Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD

On Mon, Jun 25, 2012 at 8:07 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Ruhe Julian [mailto:jruhe_at_axway.com]
>> Sent: vrijdag 22 juni 2012 14:57
>> To: Stephen Butler
>> Cc: Daniel Shahaf; users_at_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_at_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_at_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_at_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_at_10
>> >> 9
>> =>
>> >> 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.
>>
>> 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_at_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_at_50' works just fine, as long as $URL_at_50 is the same node as $URL_at_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