You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Tati, Aslesh" <at...@barclaycardus.com> on 2016/05/06 21:33:40 UTC
Subversion checkout behavior at non-existent revision
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?
Thanks,
Aslesh Tati
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.
Re: Subversion checkout behavior at non-existent revision
Posted by Stefan <lu...@posteo.de>.
On 5/10/2016 00:15, Daniel Shahaf wrote:
> Stefan Hett wrote on Mon, May 09, 2016 at 09:11:05 +0200:
>> 2) Why does the svn co command create a subdirectory 'a' instead of taking
>> the specified URL as the path to checkout entirely?
> Can you explain in more words what you expect
> .
> cd /tmp/ && svn checkout https://svn.apache.org/repos/asf/subversion/trunk/tools/
> .
> to do?
Nevermind. I just re-read the documentation on svn co and realize that
it actually does create subdirectories based on the basename in the URL.
So in combination with your other explanation on this thread everything
is sound here and I yet again learned a new detail of the svn command
line client today. :-)
TBH this is quite a surprise, since I would have assumed the PATH
defaults to "." if not explicitly specified. Given the functionality of
svn co to be able to checkout multiple paths and the general design to
help with best practices in SVN, I understand the reasoning to use a
different default behavior here however.
Regards,
Stefan
Re: Subversion checkout behavior at non-existent revision
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Hett wrote on Mon, May 09, 2016 at 09:11:05 +0200:
> 2) Why does the svn co command create a subdirectory 'a' instead of taking
> the specified URL as the path to checkout entirely?
Can you explain in more words what you expect
.
cd /tmp/ && svn checkout https://svn.apache.org/repos/asf/subversion/trunk/tools/
.
to do?
Re: Subversion checkout behavior at non-existent revision
Posted by Stefan <lu...@posteo.de>.
Hi Aslesh,
>
> Hello Stefan,
>
> Ive verified that the branch doesnt 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
> Im 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
>
I've now tried to reproduce the case using MaxSVN 1.8.15-1 [1] and with
my simple repro case am still failing to reproduce the behavior you are
describing here.
In my case I did the following steps:
1. svnadmin create E:\testRepo
2. mkdir E:\testWC
3. svn co file:///E:/testRepo E:\testWC
4. mkdir E:\testWC\trunk
5. mkdir E:\testWC\branches
6. svn add E:\testWC\*
7. svn ci E:\testWC -m"created trunk/branches"
8. svn cp file:///E:/testRepo/trunk file:///E:/testRepo/branches/a
-m"copied trunk"
9. mkdir E:\testWC2
10. svn co file:///E:/testRepo/branches/a@1 E:\testWC2
svn: E17000: URL 'file:///E:/testRepo/branches/a' doesn't exist.
Can you come up with some repro case which demonstrates the different
behavior you are experiencing?
[1] http://www.luke1410.de/typo3/fileadmin/user_upload/maxsvn_1.8.15-1.rar
Regards,
Stefan
>
> *From:*Stefan Hett [mailto:stefan@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 Im trying to check out the branch at revision 500. I know
> that the branch doesnt exist at r500 (it will be some higher
> revision), only trunk does and it probably doesnt make sense to
> check out a branch at that revision; but Im 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
>
> Shouldnt subversion complain that the branch doesnt 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.
>
RE: Subversion checkout behavior at non-existent revision
Posted by "Tati, Aslesh" <at...@barclaycardus.com>.
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:stefan@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.
Re: Subversion checkout behavior at non-existent revision
Posted by Stefan Hett <st...@egosoft.com>.
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 Im trying to check out the branch at revision 500. I know that
> the branch doesnt exist at r500 (it will be some higher revision),
> only trunk does and it probably doesnt make sense to check out a
> branch at that revision; but Im 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
>
> Shouldnt subversion complain that the branch doesnt 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
RE: Subversion checkout behavior at non-existent revision
Posted by "Tati, Aslesh" <at...@barclaycardus.com>.
It makes sense to me now.
Thank you Daniel.
-----Original Message-----
From: Daniel Shahaf [mailto:danielsh@apache.org]
Sent: Monday, May 09, 2016 6:15 PM
To: Tati, Aslesh
Cc: users@subversion.apache.org
Subject: Re: Subversion checkout behavior at non-existent revision
Tati, Aslesh wrote on Fri, May 06, 2016 at 21:33:40 +0000:
> 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?
No.
«svn checkout -r 500 <REPO_URL>/branches/<BRANCH>» means "Look what BRANCH is in rHEAD, trace copies back to r500, then operate on that", which is why it checks out trunk@r500.
«svn checkout -r 500 <REPO_URL>/branches/<BRANCH>@500» will do what you expect (error out with "does not exist at that revision").
The peg revision of URLs defaults to HEAD. The operative revision defaults to the peg revision.
http://svnbook.red-bean.com/en/1.8/svn.advanced.pegrevs.html#svn.advanced.pegrevs.algorithm
Cheers,
Daniel
> If it has checked out without complaining, why does svn info using the second way of checkout show the unexpected result?
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.
Re: Subversion checkout behavior at non-existent revision
Posted by Stefan <lu...@posteo.de>.
On 5/10/2016 00:15, Daniel Shahaf wrote:
> Tati, Aslesh wrote on Fri, May 06, 2016 at 21:33:40 +0000:
>> 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?
> No.
>
> �svn checkout -r 500 <REPO_URL>/branches/<BRANCH>� means "Look what
> BRANCH is in rHEAD, trace copies back to r500, then operate on that",
> which is why it checks out trunk@r500.
Thanks for the explanation. After you realize that the branch which is
being worked on in the given example is basically the trunk in r500,
that's all quite logical.
Regards,
Stefan
Re: Subversion checkout behavior at non-existent revision
Posted by Daniel Shahaf <da...@apache.org>.
Tati, Aslesh wrote on Fri, May 06, 2016 at 21:33:40 +0000:
> 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?
No.
�svn checkout -r 500 <REPO_URL>/branches/<BRANCH>� means "Look what
BRANCH is in rHEAD, trace copies back to r500, then operate on that",
which is why it checks out trunk@r500.
�svn checkout -r 500 <REPO_URL>/branches/<BRANCH>@500� will do what you
expect (error out with "does not exist at that revision").
The peg revision of URLs defaults to HEAD. The operative revision
defaults to the peg revision.
http://svnbook.red-bean.com/en/1.8/svn.advanced.pegrevs.html#svn.advanced.pegrevs.algorithm
Cheers,
Daniel
> If it has checked out without complaining, why does svn info using the second way of checkout show the unexpected result?