You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ruhe Julian <jr...@axway.com> on 2012/06/20 11:17:53 UTC
Issue: svn:externals syntax does not accept -rHEAD
Hello,
try to assign a file p.txt containing the following lines as svn:external
-r110 ^/mapping_services/global/testing/full_test/globalresource5.xml@110 "xml/globalresource5.xml"
-r84 ^/mapping_services/global/testing/full_test/globalresource4.xml@84 "xml/globalresource4_renamed.xml"
-r83 ^/mapping_services/global/testing/full_test/globalresource3.xml@83 "xsd/globalresource3.xml"
-r82 ^/mapping_services/global/testing/full_test/globalresource2.xml@82 "xml/globalresource2.xml"
-rHEAD ^/mapping_services/global/testing/full_test/globalresource6.xml@109 "xml/globalresource6.xml"
Fails with error
$ svn propset --file p.txt svn:externals .
svn: E195005: Error parsing svn:externals property on '/cygdrive/g/Projekte/Mapping Services/workspaces-runtime/workspace-runtime-bom26-02/ShareProjektTest3': '-rHEAD ^/mapping_services/global/testing/full_test/globalresource6.xml@109 "xml/globalresource6.xml"'
Skipping the -rHEAD part is no solution because in this case the operation-revision:=peg-revision which is obviously not the desired revision.
I was using using:
$ svn --version
svn, version 1.7.5 (r1336830)
compiled May 18 2012, 13:37:30
Greetings,
Julian
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Jun 22, 2012 at 5:19 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>
> Just to be sure, I checked what happens if you don't move the target
> of the checkout, but perform some other change below it. Sure enough,
> checkout does the right thing: it checks out the correct item, at the
> operative revision:
Does an svn cp (url->url) accept that syntax? A workaround might be
to copy to a tag first and point the external to the tag - with the
possible issue that the tag is now pinned to that version even if HEAD
is still moving (the object has not been deleted yet), but if you know
that you probably wouldn't mention the peg rev at all.
--
Les Mikesell
lesmikesell@gmail.com
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, Jun 22, 2012 at 7:47 PM, Les Mikesell <le...@gmail.com> wrote:
> 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.
Interesting thread. Like Les, I was convinced at first that you were
asking something that SVN simply cannot do (given its current design).
However, then I noticed that you said: "I want an error on my request
"-rHEAD path@peg" if the object was deleted, moved or recreated." So I
wondered what the actual behavior of checkout or update would be in
those cases (since you compared with behavior of those two
subcommands). A quick test:
[[[
C:\Temp\svntest>svnadmin create testrepos
C:\Temp\svntest>svn mkdir -mm file:///C:/Temp/svntest/testrepos/dir
Committed revision 1.
C:\Temp\svntest>svn mv -mm file:///C:/Temp/svntest/testrepos/dir
file:///C:/Temp/svntest/testrepos/dir2
Committed revision 2.
C:\Temp\svntest>svn checkout -rHEAD file:///C:/Temp/svntest/testrepos/dir@1
svn: E160013: File not found: revision 2, path '/dir'
]]]
Aha, so checkout cannot follow moves either. That's expected, because
svn doesn't know how to do forward history traversal (as already
discussed in this thread).
But if I understand correctly, that's perfectly valid behavior for
your use case: same behavior as checkout. If the object has moved etc,
an error is fine.
Just to be sure, I checked what happens if you don't move the target
of the checkout, but perform some other change below it. Sure enough,
checkout does the right thing: it checks out the correct item, at the
operative revision:
[[[
C:\Temp\svntest>svn mkdir -mm file:///C:/Temp/svntest/testrepos/dir2/subdir
Committed revision 3.
C:\Temp\svntest>svn co -rHEAD file:///C:/Temp/svntest/testrepos/dir2@2
A dir2\subdir
Checked out revision 3.
C:\Temp\svntest>dir /b dir2
subdir
]]]
Since externals (dir externals at least) are much like an embedded
checkout with some sugar on top, I think it should be doable to
implement this behavior for externals too.
Conclusion: I think you have a valid feature request. Go ahead and
file an issue.
--
Johan
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Les Mikesell <le...@gmail.com>.
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
lesmikesell@gmail.com
AW: Issue: svn:externals syntax does not accept -rHEAD
Posted by Ruhe Julian <jr...@axway.com>.
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@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@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@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@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@gmail.com]
Gesendet: Freitag, 22. Juni 2012 18:02
An: Ruhe Julian
Cc: users@subversion.apache.org
Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD
On Fri, Jun 22, 2012 at 8:11 AM, Ruhe Julian <jr...@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@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@peg" if the object was deleted, moved or recreated. Similar to the result of "svn checkout -rHEAD path@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@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@gmail.com
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Jun 22, 2012 at 8:11 AM, Ruhe Julian <jr...@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@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@peg" if the object was deleted, moved or recreated. Similar to the result of "svn checkout -rHEAD path@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@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@gmail.com
AW: Issue: svn:externals syntax does not accept -rHEAD
Posted by Ruhe Julian <jr...@axway.com>.
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@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@peg" if the object was deleted, moved or recreated. Similar to the result of "svn checkout -rHEAD path@peg". Why should svn:externals behave differently here?
Greetings,
Julian
-----Ursprüngliche Nachricht-----
Von: Les Mikesell [mailto:lesmikesell@gmail.com]
Gesendet: Freitag, 22. Juni 2012 14:55
An: Stephen Butler
Cc: Ruhe Julian; Daniel Shahaf; users@subversion.apache.org
Betreff: Re: Issue: svn:externals syntax does not accept -rHEAD
On Fri, Jun 22, 2012 at 6:19 AM, Stephen Butler <sb...@elego.de> wrote:
>
>> -rHEAD
>> ^/mapping_services/global/testing/full_test/globalresource6.xml@109
>> => 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.
I think the usual approach would be to copy to a branch at a point before you expect disruptive operations like deleting/replacing an object to happen. That is, if you branched at your rev 109 example, work on that branch could continue on its own path while the trunk
diverges in its own way. Besides giving the HEAD you are trying to
find a natural place to live, the branch also lets you give it a more
human-friendly name for the external reference. Note that you can
even wait until after the disruptive change happens and copy the
branch from an earlier rev if the changes are not predictable. Also,
when you want to absolutely nail down the referenced external revision you can copy to a tag which, by convention, has no further commits.
Subversion handles these copies efficiently and they are much easier to follow than deleting/replacing objects in the same path (both for subversion and the people using the repository).
--
Les Mikesell
lesmikesell@gmail.com
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Jun 22, 2012 at 6:19 AM, Stephen Butler <sb...@elego.de> wrote:
>
>> -rHEAD ^/mapping_services/global/testing/full_test/globalresource6.xml@109 => 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.
I think the usual approach would be to copy to a branch at a point
before you expect disruptive operations like deleting/replacing an
object to happen. That is, if you branched at your rev 109 example,
work on that branch could continue on its own path while the trunk
diverges in its own way. Besides giving the HEAD you are trying to
find a natural place to live, the branch also lets you give it a more
human-friendly name for the external reference. Note that you can
even wait until after the disruptive change happens and copy the
branch from an earlier rev if the changes are not predictable. Also,
when you want to absolutely nail down the referenced external revision
you can copy to a tag which, by convention, has no further commits.
Subversion handles these copies efficiently and they are much easier
to follow than deleting/replacing objects in the same path (both for
subversion and the people using the repository).
--
Les Mikesell
lesmikesell@gmail.com
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Les Mikesell <le...@gmail.com>.
On Fri, Jun 22, 2012 at 7:56 AM, Ruhe Julian <jr...@axway.com> wrote:
>>
>> 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.
Not to subversion. There is one path going backwards in revisions
and it tracks copy-from. Going forward, there could be many versions
copied-to and the one on the same path (which makes sense to you)
isn't special to subversion.
--
Les Mikesell
lesmikesell@gmail.com
AW: Issue: svn:externals syntax does not accept -rHEAD
Posted by Ruhe Julian <jr...@axway.com>.
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:jcorvel@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 <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Ruhe Julian [mailto:jruhe@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
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Jun 25, 2012 at 8:07 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Ruhe Julian [mailto:jruhe@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@109
>> =>
>> >> 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
RE: Issue: svn:externals syntax does not accept -rHEAD
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ruhe Julian [mailto:jruhe@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@109
> =>
> >> 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
AW: Issue: svn:externals syntax does not accept -rHEAD
Posted by Ruhe Julian <jr...@axway.com>.
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@109 =>
>> 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?
Best regards,
Julian
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Stephen Butler <sb...@elego.de>.
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@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@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@109 => 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.
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@daniel.shahaf.name]
> Gesendet: Freitag, 22. Juni 2012 01:47
> An: Ruhe Julian
> Cc: users@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@109. Is there a reason to expect that ^/mapping_services/global/testing/full_test/globalresource6.xml@HEAD and
> ^/mapping_services/global/testing/full_test/globalresource6.xml@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
RE: Issue: svn:externals syntax does not accept -rHEAD
Posted by Ruhe Julian <jr...@axway.com>.
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, 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.
-rHEAD ^/mapping_services/global/testing/full_test/globalresource6.xml@109 => 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
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@daniel.shahaf.name]
Gesendet: Freitag, 22. Juni 2012 01:47
An: Ruhe Julian
Cc: users@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@109. Is there a reason to expect that ^/mapping_services/global/testing/full_test/globalresource6.xml@HEAD and
^/mapping_services/global/testing/full_test/globalresource6.xml@r109
will at some point not be ancestrally related? If not, you could just drop both -rHEAD and @109 and get the same result.
Re: Issue: svn:externals syntax does not accept -rHEAD
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ruhe Julian wrote on Wed, Jun 20, 2012 at 09:17:53 +0000:
> Hello,
>
> try to assign a file p.txt containing the following lines as svn:external
>
> -r110 ^/mapping_services/global/testing/full_test/globalresource5.xml@110 "xml/globalresource5.xml"
> -r84 ^/mapping_services/global/testing/full_test/globalresource4.xml@84 "xml/globalresource4_renamed.xml"
> -r83 ^/mapping_services/global/testing/full_test/globalresource3.xml@83 "xsd/globalresource3.xml"
> -r82 ^/mapping_services/global/testing/full_test/globalresource2.xml@82 "xml/globalresource2.xml"
> -rHEAD ^/mapping_services/global/testing/full_test/globalresource6.xml@109 "xml/globalresource6.xml"
>
> Fails with error
> $ svn propset --file p.txt svn:externals .
> svn: E195005: Error parsing svn:externals property on '/cygdrive/g/Projekte/Mapping Services/workspaces-runtime/workspace-runtime-bom26-02/ShareProjektTest3': '-rHEAD ^/mapping_services/global/testing/full_test/globalresource6.xml@109 "xml/globalresource6.xml"'
>
> Skipping the -rHEAD part is no solution because in this case the operation-revision:=peg-revision which is obviously not the desired revision.
>
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@109. Is there a reason to expect that
^/mapping_services/global/testing/full_test/globalresource6.xml@HEAD and
^/mapping_services/global/testing/full_test/globalresource6.xml@r109
will at some point not be ancestrally related? If not, you could just
drop both -rHEAD and @109 and get the same result.
> I was using using:
> $ svn --version
> svn, version 1.7.5 (r1336830)
> compiled May 18 2012, 13:37:30
>
> Greetings,
> Julian