Hello Johan,
Yes, you understood my request correctly. I will create an issue today.
Regarding the implementation a simple, automatic replacement of "-rHEAD
path@peg" by "-r{revision of HEAD} path@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:jcor...@gmail.com]
Gesendet: Montag, 25. Juni 2012 20:54
An: Bert Huijben
Cc: Ruhe Julian; Stephen Butler; Daniel Shahaf; users@subversion.apache.org
Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD
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@10
>> >> 9
>> =>
>> >> 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
