[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Unexpected behaviour when checking out a copy at an invalid revision

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 26 May 2014 16:46:37 +0200

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-05-26 16:53:59 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.