Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.0-beta-5
-
Component/s: scm
-
Labels:None
-
Number of attachments :
Description
svn is very stubborn about this. Basically you have to have the value in <developerConnection> match the url used to check it out.
Things that will fail:
- if you pass in a different username to --username, it is not passed on to ssh
- if you specify a username in the ssh command it works, as long as the URL is the same in both. svn+ssh://bporter@foo/... is considered a different repository to svn+ssh://foo/... even if I am bporter
I think we can take a couple of steps:
- for svn+ssh, put the username in the URL instead of passing --username
- possibly check the current checkout (svn info) and derive the tag location from that, ignoring the local checkout OR if they don't match, relocate the local checkout to that of developerConnection
- use javasvn instead
Issue Links
| This issue depends upon: | ||||
| SCM-217 | workaround svn issue with svn+ssh scheme requiring to specify user@host and ignoring --username |
|
|
|
Activity
Hide
Jerome Lacoste
added a comment -
I've just been beaten by that 
Basically, --username is ignored for every command with a URLs based on svn+ssh form. Dixit darix on #svn. Will try to find a fix.
Show
Jerome Lacoste
added a comment - I've just been beaten by that
Basically, --username is ignored for every command with a URLs based on svn+ssh form. Dixit darix on #svn. Will try to find a fix.
Basically, --username is ignored for every command with a URLs based on svn+ssh form. Dixit darix on #svn. Will try to find a fix. 
additional issue to note from Greg: if the tagBase contains scm:svn or svn: instead of just the svn url, then that doesn't work without helpful error reporting