If you're using svn+ssh as your protocol to access more than one
repository, you may have already noticed that Tortoise's settings are
insufficient to meet your needs.
Summary:
If you required different user names to access two or more repositories
via svn+ssh, then Tortoise's single global ssh client setting is
insufficient to allow you to do this easily.
Details:
Here's one practical example of how this manifests itself. Say you want
access to two separate repositories via svn+ssh. For the first, your
username/password is flast/g00ber. For the second, your
username/password is firstl/gdNpl3nty. You don't have administrative
access to either of the machines on which the repositories are stored.
Neither of the machine's versions of sshd allow certificate based
authentication, at least not without administrator intervention and a
six month turn-around time (don't ask me why, but that's the way it
is).
Now say you want to check out two directories:
svn+ssh://flast:g00ber_at_svn.repos-one.dom/foo/bar
svn+ssh://firstl:gdNpl3nty_at_svn.repos-two.dom/baz/quux
So you set your ssh client in your Tortoise network settings to be:
c:\...\plink.exe -l flast -pw g00ber
Now you happily check out your first directory. But when you go to
check out your second, it asks you for your password, and "gdNpl3nty"
doesn't work. You realize that you have a problem, since the user on
the second account doesn't match the user on the first, you're not
going to be able to check out the second without going back to the
Tortoise network settings and changing your ssh client.
However, you're going to be interacting pretty heavily with both of
these repositories at the same time, and you really don't want to have
to keep changing it every time you want to switch.
Now I know that certificate-based authentication is a work-around for
this, but I'd like to make a suggestion (if I may): make the ssh client
part of the checkout dialog, and associate it with the checked out
directory.
I also know that storing such information in the directory itself is
either not going to work (since then subversion would see it). It's
probably unacceptable to use a file with a name that is ignored by
subversion by default (e.g., '.tortoise~' or something), since these
can be overridden by the repository or the user configuration.
I don't want to presume I know anything about developing Tortoise, but
the only thing I can think of is keeping a table which associates a ssh
client entry with something matching the url (e.g., machine+port) in
the .svn/entries file. This is still not a great solution, however,
since it means that one couldn't check out something from the same
repository as two different users. One would also have to do some
matching, since one probably doesn't (easily) know where the top-level
.svn directory is, and one wouldn't want to associate the SSH client
with a local path since moving that directory on local disk would break
the association. Associating them with directory IDs (sorry I'm
ignorant of fat and ntfs) wouldn't be ideal either because then they
don't work across volumes.
Okay, I am beginning to see the reason why it is a global setting....
:-)
Does subversion allow for (i.e., safely ignore) arbitrary local
properties to be associated with subversioned directories (e.g., in a
.svn/tortoise file)? If so, that might be the way to go. Just a
thought....
--Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Jul 3 11:33:36 2004