That's not to mention that the USER@ trick in the URL does not hold up
for svn:externals mappings. Each external must also have the user
mapping as well (otherwise it breaks).
Say, for example, that my repository has the following directories:
`- svnroot/
+- dev/
| +- branches/
| | `- ...
| `- trunk/
| +- utils/
| | `- ...
| +- component_a/
| | `- ...
| +- component_b/
| | `- ...
| +- component_c/
| | `- ...
| `- vendor/
| +- libabc/
| | `- ...
| `- libxyz/
| `- ...
`- vendor/
+- libabc/
| +- ...
| `- current/
| `- ...
`- libxyz/
+- ...
`- current/
`- ...
component_a requires libabc. component_b requires libxyz. component_c
requires component_b.
Now say that we have three groups of developers: a (who work
component_a), b (who work on component b) and c (who work on
component_c).
As an administrator, I can provide mappings using svn:externals so that
each developer working in "trunk" doesn't have to check out the entire
"trunk" source tree:
`- svnroot/
+- ...
`- dev/
+- ...
`- trunk/
`- groups/
+- dev_a/
| `- vendor/
+- dev_b/
| `- vendor/
`- dev_c/
`- vendor/
For svnroot/dev/trunk/groups/dev_a, my mappings are as follows:
utils svn+ssh://domain.dom/.../svnroot/dev/trunk/utils
component_a svn+ssh://domain.dom/.../svnroot/dev/trunk/component_a
For svnroot/dev/trunk/groups/dev_a/vendor, my mappings are as follows:
libabc svn+ssh://domain.dom/.../svnroot/dev/trunk/vendor/libabc
For svnroot/dev/trunk/groups/dev_b, my mappings are as follows:
utils svn+ssh://domain.dom/.../svnroot/dev/trunk/utils
component_b svn+ssh://domain.dom/.../svnroot/dev/trunk/component_b
For svnroot/dev/trunk/groups/dev_b/vendor, my mappings are as follows:
libxyz svn+ssh://domain.dom/.../svnroot/dev/trunk/vendor/libxyz
For svnroot/dev/trunk/groups/dev_c, my mappings are as follows:
utils svn+ssh://domain.dom/.../svnroot/dev/trunk/utils
component_b svn+ssh://domain.dom/.../svnroot/dev/trunk/component_b
component_c svn+ssh://domain.dom/.../svnroot/dev/trunk/component_c
For svnroot/dev/trunk/groups/dev_c/vendor, my mappings are as follows:
libxyz svn+ssh://domain.dom/.../svnroot/dev/trunk/vendor/libxyz
These are convenience mappings I set up as an administrator. (I know
this example is a little contrived, but bear with me).
So now, let's say that a developer from group "a" goes to check out his
sources to start work on the new version in trunk. Locally (on his
development station), his user name is "code4fud", but in our fair
organization he is known as "mbogosian".
When he goes to check out svnroot/dev/trunk/groups/dev_a, he may do the
following:
svn co
svn+ssh://mbogosian@domain.dom/.../svnroot/dev/trunk/groups/dev_a
This will prompt him for his password (as mbogosian) for checking out
.../dev_a. However, during the checkout process, Subversion will see
that dev_a's and dev_a/vendor's contents are mapped to other places in
the repository. It will then try to check out those mappings and use
the URLs present in the svn:externals properties, or, in other words,
the equivalent of:
svn co svn+ssh://domain.dom/.../svnroot/dev/trunk/utils
...
Note the lack of a username here. Then "code4fud" will be the implied
user, and, since "code4fud" doesn't exist on the repository machine,
the checkout will fail. This is why Subversion provides the SVN_SSH
environment variable to solve problems like this. The check out would
have been able to complete successfully, if our developer had done this
instead:
SVN_SSH='plink -l mbogosian -pw 53cr3+' svn co
svn+ssh://domain.dom/...
However, Tortoise doesn't allow the association of SVN_SSH with any
checked out tree. It's global, so one has to manually switch it each
time.
Again, I think the real solution here is to find some way to be able to
associate a value for SVN_SSH with each tree, but I don't know the best
way to do that. I keep suggesting creating a new file in the .svn/
directories, but I don't know if that's kosher.
--Matt
On Jul 3, 2004, at 16:43, Matthew Bogosian wrote:
> Thanks for the info!
>
> This is something that has changed (I think) in subversion's recent
> past (one used to have to use the SSH_SVN environment variable to
> specify the user). However, I still think it leaves the problem of the
> password. Maybe a .../.svn/svn+ssh.passwd file (base64 encoded)? I
> don't know...again, just my two cents....
>
> On Jul 2, 2004, at 21:22, Eric Hanchrow wrote:
>
>>>>>>> "Matthew" == Matthew Bogosian <mtb19@columbia.edu> writes:
>>
>> Matthew> If you're using svn+ssh as your protocol to access more
>> Matthew> than one repository, you may have already noticed that
>> Matthew> Tortoise's settings are insufficient to meet your needs.
>>
>> I used to think that too, before I realized that you can encode the
>> username in the URL, like this:
>>
>>
>> svn+ssh://matthew@matts.computer.com/home/matt/svn-repos/whatever
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jul 4 10:41:39 2004