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

Hello Les,

> I'm sort of surprised a checkout works that way either.

I hope this is an argument for expecting svn:externals to do the same.

It took me some time to understand that forward history differs from backward history fundamentally.Essentially forward history has following limitations:
- First, being located @peg, you simply cannot safely _look_ into the future of the object with a single svn command
- You can ask for the a future revision and either you'll get that revision or an error if the _same_ object is no longer existing on the same path at requested operative revision
- There is absolutely no way to re-locate an object after being deleted, copied or renamed with a single svn command. Actually it is not even possible to detect whether it was deleted, copied or renamed (from the path_at_peg perspective of course). It is comparable to the event horizon of a black hole. There is simply no information available about the object except it is no longer there. The future is hidden within the black hole. That's why "svn info/checkout/update/whatever -rHEAD path_at_peg" always returns you an error, regardless whether the object was deleted, copied or renamed

(There is one exception: If an object is moved away from its path and then back "-rHEAD path_at_peg" will return the object (in this case svn internally users backward history to validate object equality)).

This all perfectly fits the svn 1.7 documentation (Quote "Someday, we expect that Subversion will be able to handle this usage scenario with more flexibility and grace" ;) ) but unfortunately the correct bevhaiour applies not to svn:externals. I just ask for svn:externals doing the same way as _any_ other svn command accepting peg revisions and operative revisions

In another mail you asked me "How do you track the object if it is renamed, copied, or both?". I do not. For the reasons above (the limitations of forward history), in my situation lifetime (or better " mutability") of an object ends when it's renamed, copied, or both. Or in other words: If -rHEAD path_at_peg gives me an error, object is dead or immutable for projects already referencing it respectively. Period.

Thank you for your patience.

Greetings,
Julian

-----Ursprüngliche Nachricht-----
Von: Les Mikesell [mailto:lesmikesell_at_gmail.com]
Gesendet: Freitag, 22. Juni 2012 18:02
An: Ruhe Julian
Cc: users_at_subversion.apache.org
Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD

On Fri, Jun 22, 2012 at 8:11 AM, Ruhe Julian <jruhe_at_axway.com> wrote:
> Hi Les,
>
> thank you for your answer. I think I have to explain my use case a little more detailed. First, we are not talking about source code. Users will not be software developers.
>
> Ok, we have defined an area in the repo where "global objects" are stored. Those can be addressed by "projects" using svn:externals. By specification the lifetime of a global objects ends, when it is deleted or moved. The default and normal way to address global objects is by path and fixed revision. In rare cases some of them should be addressed not by a fixed revision but by "always the most recent version". This is what I cannot achieve. I cannot address it by path_at_HEAD because I could get a recreated object after deletions. But this is the wrong object to me. I want an error on my request "-rHEAD path_at_peg" if the object was deleted, moved or recreated. Similar to the result of "svn checkout -rHEAD path_at_peg". Why should svn:externals behave differently here?

I'm sort of surprised a checkout works that way either. From subversion's perspective, copying an object or renaming it or something in the containing path are equally valid things to happen to
an object as modifying the content at its current path. What does
the checkout give you with -rHEAD path_at_peg when the object or its path
has been renamed or it has been copied to multiple locations? In the
case of copies, they would still all be the object you are requesting
and might have been deleted at different future revisions. The only
real way to find what you want is to look at each revision after the peg in that path and see if it has the peg version as an ancestor .
I agree with you that it would be nice to be able to tell subversion to do that for you, but even if you could, the server would still have to use that approach to find it since it doesn't track things in the forward direction, and from its point of view it is no more likely for the object to be there than anywhere else you might have moved it.
That is, the object is tracked across revisions by the history of where it came from, not it's current name/path. But you must already understand that since you know that an object at that path in a future revision with a different history is a different object.

-- 
   Les Mikesell
       lesmikesell_at_gmail.com