Hi Stefan,
Thanks for the explanation - I always forget about the subtleties of using
-r<rev> versus @<rev>. I now understand what Subversion is doing here and why,
but I maintain that it should give some indication that the workspace is not
pointing at the "expected" repository location. Yes, it's the result of user
error (or may even be intentional), but an info or warning would be helpful.
All the best,
fergus
On 05/27/2014 02:46 AM, Stefan Sperling wrote:
> On Sun, May 11, 2014 at 07:10:47PM +1200, Fergus Slorach wrote:
>>
>> Checking out a copied directory at a revision prior to the copy results in
>> a checkout of the data before the copy. I would expect this to fail in the
>> same way that attempting to update to an invalid revision fails.
>> Is this the intended behaviour?
>
> Hi Fergus,
>
> Yes, it is. 'svn checkout -rX URL' is says: Please give me the content
> of URL as it appeared in rX, following copy history if necessary.
>
>> If so, shouldn't there be some message that
>> your working copy is using a different location than requested?
>
> Try: svn checkout URL_at_X
> This says: Please locate URL in revision X and give me its content.
> This will fail if URL doesn't actually exist in rX.
> This matches the behaviour you expected from checkout -rX, doesn't it?
>
> Subversion expects you to specify a peg revision if you want
> something from a specific revision. See this page:
> http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
>
> Note that the command you gave has an implicit peg revision of HEAD
> (HEAD being the youngest revision in the repository):
> svn co -r X URL_at_HEAD
>
>>> svn copy trunk mybranch -m 'copy test'
>> Committed revision 2
>>
>>> svn co mybranch -r1 mybranch
>>
>>> svn info mybranch
>> Relative URL: ^trunk
>>
>> Checking out the branch at a valid revision then attempting to update to the
>> earlier revision results in an error:
>>
>> svn: E160005: Target path 'mybranch' does not exist
>
> You need to use 'svn switch' to change the URL of an existing working copy.
> Again, this is by design. If working copies could be switched to different
> URLs during 'update', users might end up making commits to the wrong branch
> without realising it. (Admittedly, in your checkout -rX case, this could also
> happen -- but we can wiggle ourselves out of the resulting conundrum by claiming
> it is considered an error on behalf of the user because a peg revision should
> have been used ;)
>
> So what you tripped over is the small semantic difference between an operative
> revision and a peg revision during 'svn checkout'. This is a common mistake,
> but Subversion needs to support both cases, and users are required to learn
> about this difference to make proper use of the system.
>
> Does that make sense?
>
Received on 2014-06-20 08:22:01 CEST