subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hett <ste...@egosoft.com>
Subject Re: Subversion checkout behavior at non-existent revision
Date Mon, 09 May 2016 07:11:05 GMT
Hi Aslesh,

> Hi,
>
> I have a question about the behavior of svn checkout. Here is the 
> scenario:
>
> I have a standard trunk, branches, tags structure for one of my apps 
> in a repo and I created a branch, say at revision 500 of trunk.
>
> Later, I delete the branch and the recreate another branch with the 
> same name and at the same revision 500 of trunk.
>
> Now I’m trying to check out the branch at revision 500. I know that 
> the branch doesn’t exist at r500 (it will be some higher revision), 
> only trunk does and it probably doesn’t make sense to check out a 
> branch at that revision; but I’m interested in knowing why this 
> behavior occurs and if it is expected.
>
> svn co <REPO_URL>/branches/<BRANCH>@500 à svn info on that gives the 
> URL as expected i.e. <REPO_URL>/branches/<BRANCH>
>
> svn co -r 500 <REPO_URL>/branches/<BRANCH> à svn info on that gives an 
> unexpected result i.e. <REPO_URL>/trunk
>
> Shouldn’t subversion complain that the branch doesn’t exist at 
> revision 500?
>
> If it has checked out without complaining, why does svn info using the 
> second way of checkout show the unexpected result?
>
Which version of SVN are you using?
I just tried to reproduce the behavior you are describing here using SVN 
1.9.4.

For the first test (aka: co with a peg-revision prior to the creation of 
the branch) I'm getting the expected svn error: "svn: E170000: URL 
'<REPO_URL>/branches/<BRANCH>' doesn't exist".
Could it be possible that you somehow mistook the revisions in your case 
and the branch in fact already existed in revision 500?


The second case brings up some different behavior on my test run too - 
and I can't quite make out much sense here (even after refreshing my 
memories re-reading the peg revision algorithm):

(note: r1 was the initial creation of trunk/branches/tags folders in my 
test repository --- 'a' was the name of the test branch I created)
Running in E:\test:
svn co -r 1 <REPO_URL>/branches/a resulted in:
Checked out revision 1.

However, that then working directory in a subdirectory E:\test\a 
(instead of one in E:\test).
If I change the svn co-command and explicitly specify the wc-path, I get 
the same result you are describing (aka: co of trunk instead of the branch):
svn co -r 1 <REPO_URL>/branches/a .

TBH I would have expected the same outcome as you are describing (aka: 
some error, since the branch to be checked-out is not present in the 
given operative revision).
I've attached a repro case (Windows batch file) for this. Maybe some of 
the SVN developers can catch that up and make some sense out of that?

I take it there are two separate questions at hand here:
1) Why does the svn co command not error out, if specifying a path which 
doesn't exist in the operative revision?
2) Why does the svn co command create a subdirectory 'a' instead of 
taking the specified URL as the path to checkout entirely?

-- 
Regards,
Stefan Hett


Mime
View raw message