On Fri, Jun 22, 2012 at 12:00 PM, Ruhe Julian <jr...@axway.com> wrote:
>
>> 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.
No, it is an argument for you to more closely align your
expectations/usage to what subversion actually does.
> It took me some time to understand that forward history differs from backward
> history fundamentally.
It differs the same way as the future always differs from the past.
We can track one path back in history, but we don't know where things
will go in the future. This is slightly confusing because at the
time you make the request, everything is in the past and you know that
some HEAD exists. But you are asking subversion to start at an
earlier time and track into the future from there. And it doesn't
have a way to do that. Remember that the current path doesn't have
much to do with the object itself. With typical branch/tag usage it
is likely to be in many different paths in the future.
> 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@peg gives me an error, object is dead or immutable for projects already
> referencing it respectively. Period.
My point is that your concept of what an object is doesn't really
match what subversion does. Subversion tracks versioning history
backwards. From it's perspective you are asking a young child how its
family tree will end instead of asking a descendent who its ancestors
were and where they lived. Your question is interesting, and in fact
by the time you ask it there is some kind of answer - but not a good
way to get it.
--
Les Mikesell
lesmikes...@gmail.com
