You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Brian W. Fitzpatrick" <fi...@collab.net> on 2004/11/02 16:44:55 UTC
Re: Locking server implementation: libsvn_repos or libsvn_fs
On Oct 29, 2004, at 4:17 PM, Ben Collins-Sussman wrote:
> It seems like most of the smaller issues have dropped out of this
> thread. Allow me to oversimplify.
>
> * The remaining 'big' argument for locks-in-fs is "it's more
> convenient for
> callers."
>
> * The remaining big argument for locks-in-repos is "it's easier to
> implement".
Sorry to jump in so late here, but I haven't seen anyone bring up
gstein's big argument against locks-in-repos, namely that programs that
directly access the fs will circumvent any locks that are in-place
(e.g. SubWiki).
For the most part, I think I prefer locks-in-repos, but I just wanted
to air this one argument since I haven't seen it mentioned yet.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Brian W. Fitzpatrick" <fi...@collab.net> writes:
> On Oct 29, 2004, at 4:17 PM, Ben Collins-Sussman wrote:
>
> > It seems like most of the smaller issues have dropped out of this
> > thread. Allow me to oversimplify.
> >
> > * The remaining 'big' argument for locks-in-fs is "it's more
> > convenient for
> > callers."
> >
> > * The remaining big argument for locks-in-repos is "it's easier to
> > implement".
>
> Sorry to jump in so late here, but I haven't seen anyone bring up
> gstein's big argument against locks-in-repos, namely that programs
> that directly access the fs will circumvent any locks that are
> in-place (e.g. SubWiki).
Yeah, that bugs me too.
To be honest, I think I'm settling into the locks-in-fs camp, if only
because I see them as being consumed (implementation-wise, if not
UI-wise as well) by ACLs eventually, which I think no one debates
should live in the FS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Nov 2, 2004, at 11:19 AM, C. Michael Pilato wrote:
> "Brian W. Fitzpatrick" <fi...@collab.net> writes:
>
>>> Then they will also circumvent hooks, won't they?
>>
>> Yes. And that's really the big thing that Bugs Me. Hooks will be in
>> the repos layer, and if we implement locking policy via hooks, how
>> could we possible call the hooks from the fs layer? And the thought
>> of wrapping every fs call in a repos call makes me kind of ill.
>
> But that's the point of the repos layer. To be a wrapper for the FS
> layer. In fact, there was a time when our auth mechanisms was going
> to be entirely hook-driven, which would have meant literally wrapping
> every FS call with a repos one.
True, but that's not what we're doing right now, is it? The commit
editor provides direct calls into the fs and not wrapped calls. We can
change it to wrap all the fs calls, but is it worth it?
> As it stands with locking, we're
> talking about probably only three functions (lock, unlock, and
> is_locked), right?
Yes. And as ghudson pointed out, we can still get the locking
functionality by implementing it in the appropriate "sentinel"
functions like svn_repos_fs_commit_txn.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Brian W. Fitzpatrick" <fi...@collab.net> writes:
> > Then they will also circumvent hooks, won't they?
>
> Yes. And that's really the big thing that Bugs Me. Hooks will be in
> the repos layer, and if we implement locking policy via hooks, how
> could we possible call the hooks from the fs layer? And the thought
> of wrapping every fs call in a repos call makes me kind of ill.
But that's the point of the repos layer. To be a wrapper for the FS
layer. In fact, there was a time when our auth mechanisms was going
to be entirely hook-driven, which would have meant literally wrapping
every FS call with a repos one. As it stands with locking, we're
talking about probably only three functions (lock, unlock, and
is_locked), right?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Tue, 2004-11-02 at 12:42, Brian W. Fitzpatrick wrote:
> > We should probably start another thread to discuss this, but I'd much
> > prefer to see the lock table implemented as a DAG.
>
> So, if I have a lock on trunk/notes/releases.txt, I should necessarily
> also hold a lock on branches/1.1/notes/releases.txt if they happen to be
> the same node-rev?
Don't confuse "implemented as a DAG" with "implemented in the existing
node-revision DAG". Fitz means only the former. The rules of
inheritence need not be the same between those DAGs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 13:46, John Peacock wrote:
> And if I have set an ACL to make trunk/notes/releases.txt readonly, then
> branches/1.1/notes/releases.txt should also be readonly if they happen
> to be the same node-rev?
You're right, that's a potential problem of conceiving ACLs as mapping
node-revs to access control lists. I don't know what the answer will
be.
But this a tangent. I misunderstood what Fitz was saying; he just wants
the locking tree implementation to have a tree form so that it's fast to
query for "are there any locks within this subtree?" I wasn't talking
about the concrete implementation when I said the lock table maps
pathnames to locks, so we didn't have a real disagreement.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> So, if I have a lock on trunk/notes/releases.txt, I should necessarily
> also hold a lock on branches/1.1/notes/releases.txt if they happen to be
> the same node-rev?
And if I have set an ACL to make trunk/notes/releases.txt readonly, then
branches/1.1/notes/releases.txt should also be readonly if they happen
to be the same node-rev?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 12:42, Brian W. Fitzpatrick wrote:
> We should probably start another thread to discuss this, but I'd much
> prefer to see the lock table implemented as a DAG.
So, if I have a lock on trunk/notes/releases.txt, I should necessarily
also hold a lock on branches/1.1/notes/releases.txt if they happen to be
the same node-rev?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by Ben Collins-Sussman <su...@collab.net>.
Please take a look at notes/locking/locking-implementation.txt.
I've tried to outline a basic strategy for both locks-in-fs and
locks-in-repos.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Brian W. Fitzpatrick" <fi...@collab.net> writes:
> >> To be honest, I think I'm settling into the locks-in-fs camp, if only
> >> because I see them as being consumed (implementation-wise, if not
> >> UI-wise as well) by ACLs eventually, which I think no one debates
> >> should live in the FS.
> >
> > I don't have a strong opinion either way on repos vs. fs, but if we're
> > going to make the decision for that reason, I really really want to see
> > a design document for ACLs. Because I am not at all convinced that a
> > good implementation of a lock table (which maps pathnames to lock
> > tokens, and has no history) shares much in common with a good
> > implementation of an acl system (which maps node-revs to access control
> > lists, and may want to have history).
>
> We should probably start another thread to discuss this, but I'd much
> prefer to see the lock table implemented as a DAG.
Let's please *not* have this discussion.
I think I'm realizing now that when I used the phrase "consumed
(implementation-wise", some folks read that as my belief that these
two features will have the same basic implementation. That's not what
I meant. I meant that once we have ACLs, I see us gutting out our
implementation of locks and re-implementing them as a subset of ACLs.
Probably a poor choice of words on my part. And of course, I could be
completely off-base in that prediction, all of which is fine. But
there's no need to have that discussion right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Nov 2, 2004, at 11:17 AM, Greg Hudson wrote:
> On Tue, 2004-11-02 at 12:04, Brian W. Fitzpatrick wrote:
>>> Then they will also circumvent hooks, won't they?
>>
>> Yes. And that's really the big thing that Bugs Me. Hooks will be in
>> the repos layer, and if we implement locking policy via hooks, how
>> could we possible call the hooks from the fs layer? And the thought
>> of
>> wrapping every fs call in a repos call makes me kind of ill.
>
> Even if we implement locks in the FS, the only calls we need to wrap in
> libsvn_repos for the sake of hooks are lock and unlock, since those are
> the only calls which will trigger hook scripts.
>
> If we implement locks in the repos layer, I'll note that mod_dav_svn
> (and I hope subwiki) go through svn_repos_fs_commit_txn in order to
> trigger hooks.
A quick check of SubWiki shows that it does indeed use
svn_repos_fs_commit_txn:
http://svn.webdav.org/repos/projects/subwiki/trunk/plugins/std/
change.py
> We can put a lock check there, so things like subwiki
> won't be circumventing locks. (If an RA layer wants to check locks
> before the final stage of a commit for the sake of early rejection, it
> can do so manually or by using the libsvn_repos commit editor, but that
> argument doesn't have to do with circumvention.)
Agreed.
> CMike wrote:
>> To be honest, I think I'm settling into the locks-in-fs camp, if only
>> because I see them as being consumed (implementation-wise, if not
>> UI-wise as well) by ACLs eventually, which I think no one debates
>> should live in the FS.
>
> I don't have a strong opinion either way on repos vs. fs, but if we're
> going to make the decision for that reason, I really really want to see
> a design document for ACLs. Because I am not at all convinced that a
> good implementation of a lock table (which maps pathnames to lock
> tokens, and has no history) shares much in common with a good
> implementation of an acl system (which maps node-revs to access control
> lists, and may want to have history).
We should probably start another thread to discuss this, but I'd much
prefer to see the lock table implemented as a DAG.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 12:33, C. Michael Pilato wrote:
> And that's exactly what I was thinking when I said that. Nobody
> disputes that ACLs belong in the filesystem layer. And I believe that
> locks are just really limited ACLs.
I think there are a lot of pitfalls to thinking about locks as limited
ACLs.
In some environments, locks will be a day-to-day thing, while ACL
changes will be rare. You want to be able to view the history of ACL
changes, but if locks and unlocks are part of that history, it will be
hard to see what's going on.
If I query whether I have permission to change a file, "no" is a very
different answer from "yes, except Bob has it locked."
The ACL system should determine who has the ability to break locks and
to steal locks. But that's a very different operation from having
permission to change the acl arbitrarily.
My hunch is that, by the time we've avoided all of these pitfalls, locks
in the ACL table will feel like a completely irrelevant wart, not an
elegant special case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "C. Michael Pilato" <cm...@collab.net>.
John Peacock <jp...@rowman.com> writes:
> > I don't have a strong opinion either way on repos vs. fs, but if we're
> > going to make the decision for that reason, I really really want to see
> > a design document for ACLs. Because I am not at all convinced that a
> > good implementation of a lock table (which maps pathnames to lock
> > tokens, and has no history) shares much in common with a good
> > implementation of an acl system (which maps node-revs to access control
> > lists, and may want to have history).
>
> Except the argument can be made that locks could be implemented as
> temporary ACL's without history and a moving node-rev (if committing
> doesn't free locks, since I don't remember where that argument ended,
> if it did). If we already had ACL's, we could [quickly] have locks
> too, but locking alone isn't going to make is easier to implement
> ACL's.
And that's exactly what I was thinking when I said that. Nobody
disputes that ACLs belong in the filesystem layer. And I believe that
locks are just really limited ACLs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> I don't have a strong opinion either way on repos vs. fs, but if we're
> going to make the decision for that reason, I really really want to see
> a design document for ACLs. Because I am not at all convinced that a
> good implementation of a lock table (which maps pathnames to lock
> tokens, and has no history) shares much in common with a good
> implementation of an acl system (which maps node-revs to access control
> lists, and may want to have history).
Except the argument can be made that locks could be implemented as
temporary ACL's without history and a moving node-rev (if committing
doesn't free locks, since I don't remember where that argument ended, if
it did). If we already had ACL's, we could [quickly] have locks too,
but locking alone isn't going to make is easier to implement ACL's.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 12:04, Brian W. Fitzpatrick wrote:
> > Then they will also circumvent hooks, won't they?
>
> Yes. And that's really the big thing that Bugs Me. Hooks will be in
> the repos layer, and if we implement locking policy via hooks, how
> could we possible call the hooks from the fs layer? And the thought of
> wrapping every fs call in a repos call makes me kind of ill.
Even if we implement locks in the FS, the only calls we need to wrap in
libsvn_repos for the sake of hooks are lock and unlock, since those are
the only calls which will trigger hook scripts.
If we implement locks in the repos layer, I'll note that mod_dav_svn
(and I hope subwiki) go through svn_repos_fs_commit_txn in order to
trigger hooks. We can put a lock check there, so things like subwiki
won't be circumventing locks. (If an RA layer wants to check locks
before the final stage of a commit for the sake of early rejection, it
can do so manually or by using the libsvn_repos commit editor, but that
argument doesn't have to do with circumvention.)
CMike wrote:
> To be honest, I think I'm settling into the locks-in-fs camp, if only
> because I see them as being consumed (implementation-wise, if not
> UI-wise as well) by ACLs eventually, which I think no one debates
> should live in the FS.
I don't have a strong opinion either way on repos vs. fs, but if we're
going to make the decision for that reason, I really really want to see
a design document for ACLs. Because I am not at all convinced that a
good implementation of a lock table (which maps pathnames to lock
tokens, and has no history) shares much in common with a good
implementation of an acl system (which maps node-revs to access control
lists, and may want to have history).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Nov 2, 2004, at 11:00 AM, Greg Hudson wrote:
> On Tue, 2004-11-02 at 11:44, Brian W. Fitzpatrick wrote:
>> Sorry to jump in so late here, but I haven't seen anyone bring up
>> gstein's big argument against locks-in-repos, namely that programs
>> that
>> directly access the fs will circumvent any locks that are in-place
>> (e.g. SubWiki).
>
> Then they will also circumvent hooks, won't they?
Yes. And that's really the big thing that Bugs Me. Hooks will be in
the repos layer, and if we implement locking policy via hooks, how
could we possible call the hooks from the fs layer? And the thought of
wrapping every fs call in a repos call makes me kind of ill.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Builtin SSH tunneling support
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Wed, Nov 03, 2004 at 08:12:54PM +0100, Casper Hornstrup wrote:
>
>
> > -----Original Message-----
> > From: Mark Benedetto King [mailto:mbk@lowlatency.com]
> > Sent: 2. november 2004 21:45
> > To: Ben Collins-Sussman
> > Cc: Casper Hornstrup; 'svn-dev-list'
> > Subject: Re: Builtin SSH tunneling support
> >
> > There is work in progress to add SSL support to svnserve.
> > That should solve the problem (and replace it with the PKI problem...)
> >
> > --ben
>
> This is interresting. What is the status of this? Is there anything I can do to help?
>
> Casper
You can check out http://svn.collab.net/repos/svn/branches/svnserver-ssl.
It should work, once you make it build. We don't have any autoconf for finding
OpenSSL right now; you'll need to hack on your Makefile yourself.
For some usage information (and some hints on where to hack on your Makefile),
see:
http://svn.haxx.se/dev/archive-2004-10/1094.shtml
Disclaimer:
This functionality is being developed on a branch; it is not even part of
the official trunk, much less a release. It may not work. It may set
your house on fire. Worst of all, it may appear to be secure but not be.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Builtin SSH tunneling support
Posted by Casper Hornstrup <ch...@users.sourceforge.net>.
> -----Original Message-----
> From: Mark Benedetto King [mailto:mbk@lowlatency.com]
> Sent: 2. november 2004 21:45
> To: Ben Collins-Sussman
> Cc: Casper Hornstrup; 'svn-dev-list'
> Subject: Re: Builtin SSH tunneling support
>
> There is work in progress to add SSL support to svnserve.
> That should solve the problem (and replace it with the PKI problem...)
>
> --ben
This is interresting. What is the status of this? Is there anything I can do to help?
Casper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Builtin SSH tunneling support
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Tue, Nov 02, 2004 at 12:13:59PM -0600, Ben Collins-Sussman wrote:
>
> On Nov 2, 2004, at 11:50 AM, Casper Hornstrup wrote:
> >
> >I would like know if you would accept a patch that would enable
> >Subversion to have builtin capability to create and use such a
> >tunnel.
> >
>
> My memory tells me that Ben Reser tried to do something like this
> already, but discovered some sort of road block. Ben?
>
There is work in progress to add SSL support to svnserve. That
should solve the problem (and replace it with the PKI problem...)
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Builtin SSH tunneling support
Posted by Ben Collins-Sussman <su...@collab.net>.
On Nov 2, 2004, at 11:50 AM, Casper Hornstrup wrote:
>
> I would like know if you would accept a patch that would enable
> Subversion to have builtin capability to create and use such a
> tunnel.
>
My memory tells me that Ben Reser tried to do something like this
already, but discovered some sort of road block. Ben?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Builtin SSH tunneling support
Posted by Casper Hornstrup <ch...@users.sourceforge.net>.
> -----Original Message-----
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: 2. november 2004 19:09
> To: Casper Hornstrup
> Cc: 'svn-dev-list'
> Subject: Re: Builtin SSH tunneling support
>
> Hi! When you want to start a new thread on a mailing list,
> please don't reply to an existing message and change the
> subject. Smart mail readers will notice the hidden
> "References" or "In-Reply-To" header and thread your new
> message into the old thread, where it might get lost.
Sorry, I didn't know that.
> On Tue, 2004-11-02 at 12:50, Casper Hornstrup wrote:
> > I would like know if you would accept a patch that would enable
> > Subversion to have builtin capability to create and use
> such a tunnel.
>
> Probably not. I think it would be rather confusing two have
> two types of built-in tunnels, and there's no clear benefit
> to your type over the current type.
Hmm, I see.
>
> > P.S. I know there exist svn+ssh also but I don't like that
> users are
> > spawning private svnserve processes on the server. Nor do I like
> > giving all users full access to the repository files on the server.
>
> svnserve in daemon mode just forks off a private process for
> each new connection; it doesn't change anything to have the
> ssh process communicate over a local socket to that new
> private process.
>
> And you don't have to have a separate uid with full
> repository access for each svn+ssh user; see
> http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks for details.
> Note the last trick in particular ("Use a single Unix account
> for multiple svn users").
Is there anyone on this list that has setup svn+ssh on Windows
(Server 2003)? OpenSSH seems to crash for me during startup most of the
time. A reinstall of OpenSSH will fix it...for a few minutes ;-(
A commercial solution is acceptable to me. It just need to be stable
and easy-to-use.
Casper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Builtin SSH tunneling support
Posted by Greg Hudson <gh...@MIT.EDU>.
Hi! When you want to start a new thread on a mailing list, please don't
reply to an existing message and change the subject. Smart mail readers
will notice the hidden "References" or "In-Reply-To" header and thread
your new message into the old thread, where it might get lost.
On Tue, 2004-11-02 at 12:50, Casper Hornstrup wrote:
> I would like know if you would accept a patch that would enable
> Subversion to have builtin capability to create and use such a
> tunnel.
Probably not. I think it would be rather confusing two have two types
of built-in tunnels, and there's no clear benefit to your type over the
current type.
> P.S. I know there exist svn+ssh also but I don't like that users
> are spawning private svnserve processes on the server. Nor do I like
> giving all users full access to the repository files on the server.
svnserve in daemon mode just forks off a private process for each new
connection; it doesn't change anything to have the ssh process
communicate over a local socket to that new private process.
And you don't have to have a separate uid with full repository access
for each svn+ssh user; see
http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks for details.
Note the last trick in particular ("Use a single Unix account for
multiple svn users").
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Builtin SSH tunneling support
Posted by Casper Hornstrup <ch...@users.sourceforge.net>.
In your FAQ you explain how to access a repository using SSH
port-forwarding.
http://subversion.tigris.org/project_faq.html#paranoid says:
% ssh -L 8888:svn-server.example.com:80 me@ssh-server.example.com
% svn checkout http://localhost:8888/repos/ours
I tried this with svnserve running as a service instead and it
worked. It is however too complicated as you need two shells. One
shell for creating the tunnel and one for running the Subversion
command.
I would like know if you would accept a patch that would enable
Subversion to have builtin capability to create and use such a
tunnel.
P.S. I know there exist svn+ssh also but I don't like that users
are spawning private svnserve processes on the server. Nor do I like
giving all users full access to the repository files on the server.
Casper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking server implementation: libsvn_repos or libsvn_fs
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-11-02 at 11:44, Brian W. Fitzpatrick wrote:
> Sorry to jump in so late here, but I haven't seen anyone bring up
> gstein's big argument against locks-in-repos, namely that programs that
> directly access the fs will circumvent any locks that are in-place
> (e.g. SubWiki).
Then they will also circumvent hooks, won't they?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org