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