On 10/4/2016 12:26, Karen Pease wrote:
As it says on the tin, our connections via svn+ssh are painfully slow,
yet we can ssh into the server without any delays whatsoever. A find
on the subversion repository likewise whips through without delay, and
there's no memory or CPU load on the serve
As it says on the tin, our connections via svn+ssh are painfully slow, yet we
can ssh into the server without any delays whatsoever. A find on the
subversion repository likewise whips through without delay, and there's no
memory or CPU load on the server when people are connecting. So all sign
Hello!
I work with a redmine+svn server which manages svn access through redmine but
- out of the box - does not support per-directory restrictions.
I need to restrict write access to certain ("results", "tags") directories to
certain project members.
I know the commit-access-control.pl script
Johan Corveleyn wrote on Thu, Jul 26, 2012 at 23:55:04 +0200:
> We also talked a bit about the ^/../ in your url's, which was also a
> bit of a surprise. We didn't know about that "feature", but it seems
> to work fine, and we didn't see a problem with it. Bert ad
ontext of the current working copy.").
So I'm sorry, this was not supposed to work, and you'll need to find
another way to accomplish what you want to do.
We also talked a bit about the ^/../ in your url's, which was also a
bit of a surprise. We didn't know about that "
On Thu, Jul 26, 2012 at 2:10 AM, Johan Corveleyn wrote:
> On Thu, Jul 26, 2012 at 1:57 AM, Ryan Schmidt
> wrote:
>>
>> It's my understanding that file externals (which are a relatively new
>> feature for Subversion) are implemented very very differently under the hood
>> from directory external
On Thu, Jul 26, 2012 at 1:57 AM, Ryan Schmidt
wrote:
>
> On Jul 25, 2012, at 17:50, Benjamin Fritz wrote:
>
>> That's interesting that it works like a switch underneath. But it IS
>> very possible to pull in *directory* externals from other
>> repositories
>
> Absolutely.
>
>> which makes me wonde
On Jul 25, 2012, at 17:50, Benjamin Fritz wrote:
> That's interesting that it works like a switch underneath. But it IS
> very possible to pull in *directory* externals from other
> repositories
Absolutely.
> which makes me wonder about whether this is relevant.
It's my understanding that file
ll move together if they do move at
some point.
>> Note that this will create a "scripts" directory from repo-B in
>> repo-A's working copy, and then place a single file from repo-B into
>> the directory from repo-B. This worked fine in 1.6.17, but on upgra
7;t know
that worked. I'm not sure if that's a supported use case ...
> Note that this will create a "scripts" directory from repo-B in
> repo-A's working copy, and then place a single file from repo-B into
> the directory from repo-B. This worked fine in 1.6.17, but o
scripts
^/../repo-B/tools/coverity/README.txt scripts/README.txt
Note that this will create a "scripts" directory from repo-B in
repo-A's working copy, and then place a single file from repo-B into
the directory from repo-B. This worked fine in 1.6.17, but on upgrade
to 1.7.5, I ge
On Thu, Jun 2, 2011 at 4:54 PM, Andy Levy wrote:
> On Thu, Jun 2, 2011 at 16:47, alexus wrote:
>> ok, path based authentication how would I accomplish that?
>>
>> I'm using apache for svn, I'm not using svnserve
>>
>
> 90% of the time, the manual has the answers. This is one of those
> times.
>
On Thu, Jun 2, 2011 at 16:47, alexus wrote:
> ok, path based authentication how would I accomplish that?
>
> I'm using apache for svn, I'm not using svnserve
>
90% of the time, the manual has the answers. This is one of those
times.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbas
ok, path based authentication how would I accomplish that?
I'm using apache for svn, I'm not using svnserve
On Thu, Jun 2, 2011 at 4:17 PM, Bob Archer wrote:
> >> is there a way to restrict users to commit only to a /branches vs
> >> /trunk?
>
> > Two ways..
> >
> > 1. Path based authenticati
>> is there a way to restrict users to commit only to a /branches vs
>> /trunk?
> Two ways..
>
> 1. Path based authentication... don't give them write access.
of course I meant path based authorization here. I would like to the book here,
but it doesn't seem to be coming up.
>
> 2. Pre-commit
users@subversion.apache.org
Subject: fine
is there a way to restrict users to commit only to a /branches vs /trunk?
--
http://alexus.org/
is there a way to restrict users to commit only to a /branches vs /trunk?
--
http://alexus.org/
On Thu, Jan 6, 2011 at 1:29 AM, Nico Kadel-Garcia wrote:
> On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell wrote:
>
>> Of course you _can_ secure it. My point is that permitting ssh and
>> restricting access to ssh by itself is very likely to make your system less
>> secure (if you count on firewal
On Wed, Jan 5, 2011 at 2:19 PM, Les Mikesell wrote:
> Of course you _can_ secure it. My point is that permitting ssh and
> restricting access to ssh by itself is very likely to make your system less
> secure (if you count on firewall protections) instead of more so. And
> nothing that can be don
On 1/5/2011 1:04 PM, David Brodbeck wrote:
It's possible to do secure Subversion. Use svn+ssh access,
disable or
block other services at the firewall,
If ssh is permitted and you didn't personally set it up, what are
the odds that port tunneling or ssh's built i
On Mon, Jan 3, 2011 at 8:46 AM, Les Mikesell wrote:
> On 1/2/2011 9:43 PM, Nico Kadel-Garcia wrote:
>
>>
>> It's possible to do secure Subversion. Use svn+ssh access, disable or
>> block other services at the firewall,
>>
>
> If ssh is permitted and you didn't personally set it up, what are the o
On Mon, Jan 3, 2011 at 11:46 AM, Les Mikesell wrote:
> On 1/2/2011 9:43 PM, Nico Kadel-Garcia wrote:
>>
>> It's possible to do secure Subversion. Use svn+ssh access, disable or
>> block other services at the firewall,
>
> If ssh is permitted and you didn't personally set it up, what are the odds
>
On 1/2/2011 9:43 PM, Nico Kadel-Garcia wrote:
It's possible to do secure Subversion. Use svn+ssh access, disable or
block other services at the firewall,
If ssh is permitted and you didn't personally set it up, what are the
odds that port tunneling or ssh's built in socks proxy will allow acc
ant it.
>
> Ahem. Subversion security is not goat. Goat is fine eating, from the
> Caribbean to the middle east and central and southern Asia. Subversion
> security is *roadkill*. At the top end, Apache security is venison; a
> delicacy that many would be happy to pay for or in
24 matches
Mail list logo