Hello again,
I did read the chapter, i understand that svn+ssh:// makes a remote
connection then acts like file://. But then you say that file:// breaks
permissions by default if you have multiple users, and requires a hack
to work properly. That's where my original question came in -- I
already knew how svn+ssh:// worked, only i didn't know it was broken
because file:// was broken. I was then puzzled why svn+ssh:// didn't
act like svn://, so i made that suggestion. I was then confronted that
I was confused about how svn+ssh:// worked. I'm not confused, i'm
asking why doesn't it work like the port-forwarding you described. I
imagine many people are befuddled by this same ordeal, and would have
no problem running a daemon if it means it will work by default :) But
in the end i was hoping for an answer like: "well, nobody thought that
the file:// method would bork the repository, and now we have to wait
for the fix." not "there's no magic way to make it work out of the
box."
So, my suggestion to you, or whoever else is following, is that since
svn:// works with a daemon, why not have svn+ssh:// work with a daemon
as well? Just have it act like a port-forwarded svn:// -- that's
probably how most people expect it to work anyway. Then it won't be a
problem to the migrating CVS users who think "hey, this looks like a
tunneled pserver setup." I mean, it even has svn:// in the name
already, it's a logical step on the user-side (as opposed to
file+ssh:// :P). It also takes care of that whole "single point of DB
access" problem you mentioned earlier.
just my 2¢ -- naturally i'm gonna be port-forwarding a svnserve -d or
using the umask hack until this change is made. I just wish that's what
it did in the first place, because that's what my impression was of it.
It's also the only way this will work for people right off the bat,
until the fixes Greg mentioned are made to file://.
To you, and all who helped, i didn't realize that file:// had
permission problems, thanks for helping me realize that was the
problem, not anything else crazy I was doing.
- paul
On May 26, 2004, at 5:39 PM, Ben Collins-Sussman wrote:
> Have you read the book? Specifically chapter 6?
>
> svn+ssh:// doesn't "create an ssh tunnel and connect to an svnserve
> daemon that's already running." It uses ssh as if it were the 'rsh'
> command. It launches a temporary, private 'svnserve' process running
> as
> *you*, which then opens the database. Thus it's no different than
> using
> a file:/// URL on the server box. And if your umask and group
> membership isn't just right, you risk messing up permissions for
> everyone else.
>
> That said, you *could* use ssh port-forwarding, which is what I think
> you're imagining. You could set 'svnserve -d' running as single user
> on
> a machine behind a firewall, then set up ssh to do port-forwarding.
> Just forward local port 3690 to remotehost port 3690, and connect to
> svn://localhost/. That creates a permanent ssh "tunnel" between the
> two
> boxes, over which you connect to the svnserve daemon.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 27 02:41:39 2004