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_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.
>>
>> 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
Received on 2012-06-25 20:54:34 CEST