Hello Stefan, I've verified that the branch doesn't exist at revision 500 and only trunk has revision 500.
I should have mentioned the subversion server and the client version in my initial email. These are the server and the client versions that I'm using. svnadmin --version svnadmin, version 1.8.13 (r1667537) compiled Mar 23 2015, 11:55:34 on x86_64-unknown-linux-gnu svn --version svn, version 1.8.13 (r1667537) compiled Mar 23 2015, 11:55:34 on x86_64-unknown-linux-gnu Thanks, Aslesh Tati From: Stefan Hett [mailto:ste...@egosoft.com] Sent: Monday, May 09, 2016 3:11 AM To: users@subversion.apache.org Subject: Re: Subversion checkout behavior at non-existent revision 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 Barclaycard www.barclaycardus.com<http://www.barclaycardus.com> This email and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on.
