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

On Jun 22, 2012, at 10:32 , Ruhe Julian wrote:

> Hello Daniel,
>
> Besides the fact that there is no good reason why svn:externals does _not_ accept -rHEAD, which is unexpected behavior, since any command does accept -rHEAD,

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.

> let me explain my use case:
>
> Actually I am trying to track only one specific object (o) per path and I point to it with given peg. But as operating revision I want to have always the most recent revision in my wc. If someone deletes the object (o) I track and creates a new one (o') on the same path, I am not interested in the new object (o'). In this case svn update should tell me that my object (o) does no longer exist on HEAD. So, yes, there is a good reason to expect that @r109 and @HEAD are not ancestrally related.

There was a detailed description of the problem on this list a year ago.

  http://svn.haxx.se/users/archive-2011-03/0262.shtml

This is similar to a feature suggestion for a '--'svn log': to show the
revisions at a given URL without following copy-operations.

  http://svn.haxx.se/users/archive-2009-12/0219.shtml

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?
Should the search stop at the first deletion or keep going? What if the
next item at that URL has a different type (dir/file/symlink)? You might
want the search to stop, another user might want it to continue through
the history of the item with the different type. The options seem to be
multiplying.

The 'svn update' code is already pretty complicated (handling mixed
revisions, '--depth' exclusions, tree conflicts, etc, etc) without adding a big
"search for the right target version" feature to it.

>
> -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.

Regards,
Steve

>
> Unfortunately you cannot expect the user which is going use our software to fix the problem by hand. We will provide a very limited view to the underlying version control system, though the user will not have the chance to call any svn command at all.
>
> I think my use case is not completely remote. I hope I can create an issue for it.
>
> Greetings,
> Julian
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Gesendet: Freitag, 22. Juni 2012 01:47
> An: Ruhe Julian
> Cc: users_at_subversion.apache.org
> Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD
>
> You're asking svn to trace history forward. (from r109 to rHEAD.) In general there will be N places in rHEAD that are related to gr6.xml_at_109. Is there a reason to expect that ^/mapping_services/global/testing/full_test/globalresource6.xml_at_HEAD and
> ^/mapping_services/global/testing/full_test/globalresource6.xml_at_r109
> will at some point not be ancestrally related? If not, you could just drop both -rHEAD and @109 and get the same result.

-- 
Stephen Butler
Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Building 12
13355 Berlin, Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elego.de
Geschäftsführer: Olaf Wagner, Michael Diers
Sitz der Gesellschaft: Berlin
Handelsregister: Amtsgericht Charlottenburg HRB 77719