Re: Limited subdirectory access

[Thorsten Schöning]

Guten Tag K F,
am Montag, 30. Januar 2012 um 23:20 schrieben Sie:

> [ABC:/DEF]
> @dev = r
> @dev1 = rw

> Do I need the ABC in the front?

If it's just one repository your configuring your authz file for,your
shouldn't need to specify ABC, so try without. If this doesn't work,
you really should provide the whole authz file with access rules for
all paths, groups, members and describe with which user you login and
can commit to which folder.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Unable to checkout/add hidden files to repo

[Daniel Shahaf]

Probably a bogus httpd config --- overly greedy application of a "don't
GET .htaccess" directive.  Try files called .ABC

Jon Grimes wrote on Mon, Jan 30, 2012 at 19:32:27 -0500:
> Hello,
> 
> I'm having a strange problem and because it has to do with hidden files I'm
> having a real hard time finding any information about it.  everything
> is usually about the .svn folders.
> 
> Essentially my repository wont let me check out or commit any hidden files.
> (.htaccess)

Re: svn status returns incorrect results on Windows 7

[Johan Corveleyn]

On Tue, Jan 31, 2012 at 3:35 AM, Justin Johnson
 wrote:
> On Sun, Jan 29, 2012 at 3:25 PM, Konstantin Kolinko
>  wrote:
>> 2012/1/27 Justin Johnson :
>>> Hi,
>>>
>>> I am running Subversion 1.7.2 64 bit installer from CollabNet on
>>> Windows 7.  The problem I'm experiencing can be seen in the output
>>> below.  In summary, svn status is returning incorrect results,
>>> sometimes not showing that something has been modified and sometimes
>>> not recognizing that I'm in a working copy.  This happens for me no
>>> matter how many times I recreate the working copy, and it happens if I
>>> store the working copy in C:\Users... as below or in C:\work.  I do
>>> not have the same problem when trying to reproduce the problem with
>>> svn 1.7.2 on Solaris.
>>>
>>> PS C:\Users\myuser\wc> svn st
>>> M       a\b\file.txt
>>> PS C:\Users\myuser\wc> cd a
>>> PS C:\Users\myuser\wc\a> svn st
>>> PS C:\Users\myuser\wc\a> cd b
>>> PS C:\Users\myuser\wc\a\b> svn st
>>> svn: warning: W155007: '.' is not a working copy
>>>
>>> Does anyone know why this is happening?  I searched for this problem
>>> and only found TortoiseSVN users complaining about it, and some
>>> suggestions to make sure the user has full control of the filesystem.
>>> I did this without resolution, but decided to post here since it is a
>>> Subversion issue (with Windows 7 perhaps) and not a TortoiseSVN issue.
>>>
>>
>> It can happen because of wrong capitalization in the path.
>>
>> Are "a" and "b" real names? Are you able to reproduce this with the
>> Greek tree (repro-template.bat) [1]? Did you do the checkout with
>> command-line client or with Tortoise?
>>
>>
>> AFAIK, Tortoise 1.7.3+ does some additional work to normalize paths
>> before passing them to Subversion library methods. (TSVN issue 156.
>> There was notorious bug in that code - issue 169. Fixed in TSVN 1.7.4
>> [2]).
>>
>> In my experience Windows command shell also does some normalization
>> when I do "cd" command.
>>
>>
>> [1] 
>> http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
>> [2] http://code.google.com/p/tortoisesvn/issues/detail?id=156
>> http://code.google.com/p/tortoisesvn/issues/detail?id=169
>>
>> Best regards,
>> Konstantin Kolinko
>
> Thank you so much for the reply.  It *does* have to do with
> capitalization.  I never would have guessed that.  If I cd into
> directories and always use the correct case, the commands work fine
> every time.  If I cd into a path using the incorrect case, I of course
> am able to cd but then svn doesn't return the correct results.
>
> Does anyone know if there are plans to fix this behavour in Subversion
> as opposed to working around them in TortoiseSVN?

It's not clear to me whether this is a problem in Subversion core (in
which case TSVN now has a good workaround, but it should really be
fixed in SVN), or TSVN calling the API in an incorrect way (in which
case the only fix is in TSVN --- it could also still be a "bug" in the
specs of the API of course).

Maybe this is the same issue as the one reported here:

http://svn.haxx.se/dev/archive-2012-01/0247.shtml

AFAIK, Bert Huijben was looking into that, but I'm not sure whether
he's close to fixing it.

-- 
Johan

RE: Limited subdirectory access

[Cooke, Mark]

> -Original Message-
> From: K F [mailto:cmkfo...@yahoo.com] 
> Sent: 30 January 2012 20:40
> To: users@subversion.apache.org
> Subject: Limited subdirectory access 
> 
> We have repo ABC with 40+ subdirectories. Current svn 
> security allows developers rw permissions and qa read only to 
> ABC. We would like to have a subgroup of dev to have access 
> to subdirectory DEF (ABC/DEF). Is there a way of doing this, 
> or does the parent directory access take precedent?
> 
> Thanks,
> Rich
> 

http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html

The most specific access takes precedent.  You would need to 'revoke' the 
normal developer's access to the subdir (if I understand you correctly) by 
assigning either 'r' or just nothing to their group...

~ mark c

RE: Limited subdirectory access

[Cooke, Mark]

Dang, missed all the other replies, sorry... 

> -Original Message-
> From: Cooke, Mark 
> Sent: 31 January 2012 09:25
> To: K F; users@subversion.apache.org
> Subject: RE: Limited subdirectory access 
> 
> > -Original Message-
> > From: K F [mailto:cmkfo...@yahoo.com] 
> > Sent: 30 January 2012 20:40
> > To: users@subversion.apache.org
> > Subject: Limited subdirectory access 
> > 
> > We have repo ABC with 40+ subdirectories. Current svn 
> > security allows developers rw permissions and qa read only to 
> > ABC. We would like to have a subgroup of dev to have access 
> > to subdirectory DEF (ABC/DEF). Is there a way of doing this, 
> > or does the parent directory access take precedent?
> > 
> > Thanks,
> > Rich
> > 
> 
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbaseda
> uthz.html
> 
> The most specific access takes precedent.  You would need to 
> 'revoke' the normal developer's access to the subdir (if I 
> understand you correctly) by assigning either 'r' or just 
> nothing to their group...
> 
> ~ mark c
> 

RE: Can relocate from a svnserve based server that was 'svn sync' to a new http based server

[Tony Sweeney]

From: Brent Webster [mailto:bwebs...@belairnetworks.com]
Sent: 31 January 2012 03:08
To: users@subversion.apache.org
Cc: Brent Webster
Subject: Can relocate from a svnserve based server that was 'svn sync' to a new 
http based server

I have numerous large svn repositories accessible by svnserve on an older linux 
server that I'm moving to a new VMWare VM server using http authentication.  
I'm using svnsync to transfer the older "svn://" repositories to the new 
"http://"; repositories.  The problem that I'm having is trying to "relocate" 
the existing checked out "svn://" based working copy and point it to the new 
"http://"; repository.  An example existing WC:
svn@svna: svn info
Path: .
Working Copy Root Path: /home/svn/bin
URL: svn://svnrepo/BelAir/admin/main/svnserver/bin
Repository Root: svn://svnrepo/BelAir/admin
Repository UUID: ad8b7147-7818-0410-a3fb-ed15fa4e4e0d
Revision: 256
Node Kind: directory
Schedule: normal
Last Changed Author: bwebster
Last Changed Rev: 256
Last Changed Date: 2012-01-30 16:38:51 -0500 (Mon, 30 Jan 2012)

I've tried numerous command syntax combinations like
svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin 
svn://svnrepo/BelAir/admin/main/svnserver/bin
svn relocate svn://svnrepo/BelAir/admin/main/svnserver/bin 
http://svnrepo2:18080/svn/admin/main/svnserver/bin
svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin .

This is the type of error message:
svn@svna: svn relocate http://svnrepo2:18080/svn/admin/main/svnserver/bin .
svn: E195009: The repository at 
'http://svnrepo2:18080/svn/admin/main/svnserver/bin' has uuid 
'65d03f8f-4f6b-4b7c-8505-7ddab04e9aed', but the WC has 
'ad8b7147-7818-0410-a3fb-ed15fa4e4e0d'

What am I doing wrong (i.e. hopefully I'm doing something wrong).

For this to work, both the old and new repositories must have the same UUID. 
You should change the UUID of the new repository to match the old one. You can 
do this using the svnadmin command on the server hosting the new repository:

[sweeney@luke ~]$ svnadmin --help setuuid
setuuid: usage: svnadmin setuuid REPOS_PATH [NEW_UUID]
Reset the repository UUID for the repository located at REPOS_PATH. If
NEW_UUID is provided, use that as the new repository UUID; otherwise,
generate a brand new UUID for the repository.
[sweeney@luke ~]$

Once this is done, one of your relocate commands should work as you intend.

Tony.




Thanks Brent




This email, including any attachments, may contain confidential information, 
privileged material (including material protected by solicitor-client and/or 
other applicable privileges) or constitute non-public information under 
securities law(s). Any exploitation of the information contained in this email 
(including any attachments) by anyone other than the intended recipient is 
prohibited. If you have received this email in error, please reply to the 
sender and delete this information from your system as soon as reasonably 
practicable. Use, dissemination, distribution, reproduction, publication or any 
other exploitation of this email by unintended recipients is not authorized and 
may be unlawful.


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4776 - Release Date: 01/30/12

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Re: Unable to checkout/add hidden files to repo

[Jon Grimes]

This happens with any hidden file, not just .htaccess files.

Any idea's?

On Tue, Jan 31, 2012 at 3:19 AM, Daniel Shahaf wrote:

> Probably a bogus httpd config --- overly greedy application of a "don't
> GET .htaccess" directive.  Try files called .ABC
>
> Jon Grimes wrote on Mon, Jan 30, 2012 at 19:32:27 -0500:
> > Hello,
> >
> > I'm having a strange problem and because it has to do with hidden files
> I'm
> > having a real hard time finding any information about it.  everything
> > is usually about the .svn folders.
> >
> > Essentially my repository wont let me check out or commit any hidden
> files.
> > (.htaccess)
>

Re: Unable to checkout/add hidden files to repo

[Ryan Schmidt]

On Jan 31, 2012, at 06:47, Jon Grimes wrote:
> On Tue, Jan 31, 2012 at 3:19 AM, Daniel Shahaf wrote:
>> Jon Grimes wrote on Mon, Jan 30, 2012 at 19:32:27 -0500:
>>> Essentially my repository wont let me check out or commit any hidden files.
>>> (.htaccess)
>> 
>> Probably a bogus httpd config --- overly greedy application of a "don't
>> GET .htaccess" directive.  Try files called .ABC
> 
> This happens with any hidden file, not just .htaccess files.
> 
> Any idea's?

I agree with Daniel. Check your httpd.conf, and all other conf files it 
includes, for directives that restrict hidden files (where by "hidden files" I 
am assuming you mean files whose names begin with a ".").

Re: Limited subdirectory access

[K F]

I had already tried

[/DEF]
@dev = r
@dev1 = rw

and that did not work.

--- On Tue, 1/31/12, Thorsten Schöning  wrote:

> From: Thorsten Schöning 
> Subject: Re: Limited subdirectory access
> To: users@subversion.apache.org
> Date: Tuesday, January 31, 2012, 8:04 AM
> Guten Tag K F,
> am Montag, 30. Januar 2012 um 23:20 schrieben Sie:
> 
> > [ABC:/DEF]
> > @dev = r
> > @dev1 = rw
> 
> > Do I need the ABC in the front?
> 
> If it's just one repository your configuring your authz file
> for,your
> shouldn't need to specify ABC, so try without. If this
> doesn't work,
> you really should provide the whole authz file with access
> rules for
> all paths, groups, members and describe with which user you
> login and
> can commit to which folder.
> 
> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
> 
> -- 
> Thorsten Schöning       E-Mail:thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
> 
> Telefon.030-2 1001-310
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
> 
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789
> Hameln
> AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
> 
>

Re: Unable to checkout/add hidden files to repo

[Jon Grimes]

You guys were right.  I found the below line in my httpd.conf with a note
saying i added it in April of 2010

RedirectMatch 404 /\\..*(/.*|$)

I don't understand how I'm just now having this problem though. Doesn't
make any sense.

Thanks for you help.

On Tue, Jan 31, 2012 at 8:05 AM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

> On Jan 31, 2012, at 06:47, Jon Grimes wrote:
> > On Tue, Jan 31, 2012 at 3:19 AM, Daniel Shahaf wrote:
> >> Jon Grimes wrote on Mon, Jan 30, 2012 at 19:32:27 -0500:
> >>> Essentially my repository wont let me check out or commit any hidden
> files.
> >>> (.htaccess)
> >>
> >> Probably a bogus httpd config --- overly greedy application of a "don't
> >> GET .htaccess" directive.  Try files called .ABC
> >
> > This happens with any hidden file, not just .htaccess files.
> >
> > Any idea's?
>
> I agree with Daniel. Check your httpd.conf, and all other conf files it
> includes, for directives that restrict hidden files (where by "hidden
> files" I am assuming you mean files whose names begin with a ".").
>
>
>

RE: Limited subdirectory access

[K F]

--- On Tue, 1/31/12, Cooke, Mark  wrote:

> From: Cooke, Mark 
> Subject: RE: Limited subdirectory access
> To: "K F" , "users@subversion.apache.org" 
> 
> Date: Tuesday, January 31, 2012, 9:25 AM
> > -Original Message-
> > From: K F [mailto:cmkfo...@yahoo.com]
> 
> > Sent: 30 January 2012 20:40
> > To: users@subversion.apache.org
> > Subject: Limited subdirectory access 
> > 
> > We have repo ABC with 40+ subdirectories. Current svn 
> > security allows developers rw permissions and qa read
> only to 
> > ABC. We would like to have a subgroup of dev to have
> access 
> > to subdirectory DEF (ABC/DEF). Is there a way of doing
> this, 
> > or does the parent directory access take precedent?
> > 
> > Thanks,
> > Rich
> > 
> 
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
> 
> The most specific access takes precedent.  You would
> need to 'revoke' the normal developer's access to the subdir
> (if I understand you correctly) by assigning either 'r' or
> just nothing to their group...
> 
> ~ mark c
> 
I tried without anything and still no good

[/DEF]
@dev = 
@dev1 = rw


I have setup a test repo called sandbox with some subdirectories. Here is my 
authz file minus all the commented out lines:

[aliases]

[groups]
dev = rcrespo, test
dev1 = test
qa = qagroup

[/DEF]
@dev = 
@dev1 = rw

[/]
@dev = rw
@qa = r

I am still able to commit files in the DEF directory using the rcrespo login.

Re: Unable to checkout/add hidden files to repo

[Ryan Schmidt]

On Jan 31, 2012, at 07:18, Jon Grimes wrote:

> You guys were right.  I found the below line in my httpd.conf with a note 
> saying i added it in April of 2010
> 
> RedirectMatch 404 /\\..*(/.*|$)
> 
> I don't understand how I'm just now having this problem though. Doesn't make 
> any sense.

You mentioned server version 1.5.1 but not client version. Subversion 1.7 
includes a new http implementation which is different from the old Subversion 
1.6-and-earlier http implementation; I'm not sure if that requires a 1.7 server 
as well. If so, then there's still the serf vs neon difference; Subversion 
clients can use either, and they behave differently.

Re: Unable to checkout/add hidden files to repo

[Daniel Shahaf]

Did you upgrade your client recently?

Jon Grimes wrote on Tue, Jan 31, 2012 at 08:18:36 -0500:
> You guys were right.  I found the below line in my httpd.conf with a note
> saying i added it in April of 2010
> 
> RedirectMatch 404 /\\..*(/.*|$)
> 
> I don't understand how I'm just now having this problem though. Doesn't
> make any sense.
> 
> Thanks for you help.
> 
> On Tue, Jan 31, 2012 at 8:05 AM, Ryan Schmidt <
> subversion-20...@ryandesign.com> wrote:
> 
> > On Jan 31, 2012, at 06:47, Jon Grimes wrote:
> > > On Tue, Jan 31, 2012 at 3:19 AM, Daniel Shahaf wrote:
> > >> Jon Grimes wrote on Mon, Jan 30, 2012 at 19:32:27 -0500:
> > >>> Essentially my repository wont let me check out or commit any hidden
> > files.
> > >>> (.htaccess)
> > >>
> > >> Probably a bogus httpd config --- overly greedy application of a "don't
> > >> GET .htaccess" directive.  Try files called .ABC
> > >
> > > This happens with any hidden file, not just .htaccess files.
> > >
> > > Any idea's?
> >
> > I agree with Daniel. Check your httpd.conf, and all other conf files it
> > includes, for directives that restrict hidden files (where by "hidden
> > files" I am assuming you mean files whose names begin with a ".").
> >
> >
> >

tortoisesvn browser vs win repo browser

[MM]

Hello,
I have a svn server configured with https.
I managed to browse the repo from a web browser (chrome) where it did ask me
for auth username and passwd.
However, using the exact same https://ipaddress as I used in the browser, 
win repo browser of tortoisesvn fails saying "OPTIONS of https://ipaddress
could not connect to server.

The tortoisesvn repo browser has worked from another IP area.

regards,

MM

Re: Unable to checkout/add hidden files to repo

[Daniel Shahaf]

Ryan Schmidt wrote on Tue, Jan 31, 2012 at 07:33:03 -0600:
> 
> On Jan 31, 2012, at 07:18, Jon Grimes wrote:
> 
> > You guys were right.  I found the below line in my httpd.conf with a note 
> > saying i added it in April of 2010
> > 
> > RedirectMatch 404 /\\..*(/.*|$)
> > 
> > I don't understand how I'm just now having this problem though. Doesn't 
> > make any sense.
> 
> You mentioned server version 1.5.1 but not client version. Subversion
> 1.7 includes a new http implementation which is different from the old
> Subversion 1.6-and-earlier http implementation; I'm not sure if that
> requires a 1.7 server as well.

It requires a 1.7 mod_dav_svn configured without
a "SVNAdvertiseV2Protocol off" directive.

http://subversion.apache.org/docs/release-notes/1.7#new-feature-compatibility-table

(I know you know that link :))

> If so, then there's still the serf vs
> neon difference; Subversion clients can use either, and they behave
> differently.
> 
> 

Re: Limited subdirectory access

[Stefan Sperling]

On Tue, Jan 31, 2012 at 05:22:15AM -0800, K F wrote:
> I tried without anything and still no good
> 
> [/DEF]
> @dev = 
> @dev1 = rw
> 
> 
> I have setup a test repo called sandbox with some subdirectories. Here is my 
> authz file minus all the commented out lines:
> 
> [aliases]
> 
> [groups]
> dev = rcrespo, test
> dev1 = test
> qa = qagroup
> 
> [/DEF]
> @dev = 
> @dev1 = rw
> 
> [/]
> @dev = rw
> @qa = r
> 
> I am still able to commit files in the DEF directory using the rcrespo login.

Hmmm... I think you'll have to revoke the dev's group rw access on the root.
Then grant write permissions to subtrees individually. I suspect this is
because permissions for all path components are combined to form the final
set of permissions for a given full path.

The book was wrong about this for a long time.
It claimed that permissions for earlier components of a path were
overridden by permissions for later components, which is incorrect.

When the error was found we decided to change the book instead of
changing to code to avoid breaking existing authz setups that rely
on this behaviour.
This snippet from the book tries to explain this. But it's not very
clear because it only talks about individual users vs. group
permissions:

  "Another important fact is that group permissions are not overridden by
  individual user permissions. Rather, the combination of all matching
  permissions is granted. In the prior example, Jane is a member of the
  paint-developers group, which has read/write access. Combined with the
  jane = r rule, this still gives Jane read/write access. Permissions for
  group members can only be extended beyond the permissions the group
  already has. Restricting users who are part of a group to less than
  their group's permissions is impossible."
  http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html

I suspect the same holds for group vs. group permissions, i.e. you cannot
restrict permissions for the 'dev' group anywhere in the tree since
you've already granted rw permissions on the root folder.

So, assuming your 'dev' group is working in subtrees /ABC and /GHI
I think you'll need:

 [groups]
 dev = rcrespo, test
 dev1 = test
 qa = qagroup
 
 [/]
 # no access at all for 'dev' at the root:
 @dev =
 @qa = r
 
 [/DEF]
 # the following commented line is now implied so not needed:
 #@dev = 
 @dev1 = rw
 
 # grant 'dev' read-write on subtrees they need:
 [/ABC]
 @dev = rw
 [/GHI]
 @dev = rw

Does this work as expected?

Re: tortoisesvn browser vs win repo browser

[Ryan Schmidt]

On Jan 31, 2012, at 07:40, MM wrote:

> I have a svn server configured with https.
> I managed to browse the repo from a web browser (chrome) where it did ask me
> for auth username and passwd.
> However, using the exact same https://ipaddress as I used in the browser, 
> win repo browser of tortoisesvn fails saying "OPTIONS of https://ipaddress
> could not connect to server.
> 
> The tortoisesvn repo browser has worked from another IP area.

When you browse a repository in a web browser, only GET requests get sent. But 
when you use a real Subversion client, like TortoiseSVN, it uses other WebDAV 
methods, including OPTIONS. What you're seeing could be the result of a proxy 
that's not configured to pass WebDAV methods. Try disabling the use of the 
proxy, or if that's not possible, talk to your proxy administrator about 
supporting WebDAV methods.

Re: Limited subdirectory access

[Andy Levy]

On Tue, Jan 31, 2012 at 08:22, K F  wrote:
>
>
> --- On Tue, 1/31/12, Cooke, Mark  wrote:
>
>> From: Cooke, Mark 
>> Subject: RE: Limited subdirectory access
>> To: "K F" , "users@subversion.apache.org" 
>> 
>> Date: Tuesday, January 31, 2012, 9:25 AM
>> > -Original Message-
>> > From: K F [mailto:cmkfo...@yahoo.com]
>>
>> > Sent: 30 January 2012 20:40
>> > To: users@subversion.apache.org
>> > Subject: Limited subdirectory access
>> >
>> > We have repo ABC with 40+ subdirectories. Current svn
>> > security allows developers rw permissions and qa read
>> only to
>> > ABC. We would like to have a subgroup of dev to have
>> access
>> > to subdirectory DEF (ABC/DEF). Is there a way of doing
>> this,
>> > or does the parent directory access take precedent?
>> >
>> > Thanks,
>> > Rich
>> >
>>
>> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
>>
>> The most specific access takes precedent.  You would
>> need to 'revoke' the normal developer's access to the subdir
>> (if I understand you correctly) by assigning either 'r' or
>> just nothing to their group...
>>
>> ~ mark c
>>
> I tried without anything and still no good
>
> [/DEF]
> @dev =
> @dev1 = rw
>
>
> I have setup a test repo called sandbox with some subdirectories. Here is my 
> authz file minus all the commented out lines:
>
> [aliases]
>
> [groups]
> dev = rcrespo, test
> dev1 = test
> qa = qagroup

I can't explain why, and maybe it's been fixed in a later version, but
I seem to recall having an issue with path-based authorization when
the groups were defined with spaces. IOW, this:

dev = rcrespo, test

did not work properly but this:

dev = rcrespo,test

did.

Re: Limited subdirectory access

[Philip Martin]

Stefan Sperling  writes:

> On Tue, Jan 31, 2012 at 05:22:15AM -0800, K F wrote:
>> [groups]
>> dev = rcrespo, test
>> dev1 = test
>> qa = qagroup
>> 
>> [/DEF]
>> @dev = 
>> @dev1 = rw
>> 
>> [/]
>> @dev = rw
>> @qa = r
>> 
>> I am still able to commit files in the DEF directory using the rcrespo login.
>
> Hmmm... I think you'll have to revoke the dev's group rw access on the root.
> Then grant write permissions to subtrees individually. I suspect this is
> because permissions for all path components are combined to form the final
> set of permissions for a given full path.
>
> The book was wrong about this for a long time.
> It claimed that permissions for earlier components of a path were
> overridden by permissions for later components, which is incorrect.

I think that's misleading.  The error in the book involved a user
matching multiple lines for a single location, like the user 'test'
above.  When that happens the user gets the union of all the
permissions, the book mistakenly claimed the first matching line was
used.

Using the rules above in a file z.z:

$ tools/server-side/svnauthz-validate z.z rcrespo /ABC
user 'rcrespo' has rw access to '/ABC'
$ tools/server-side/svnauthz-validate z.z rcrespo /DEF
user 'rcrespo' has no access to '/DEF'
$ tools/server-side/svnauthz-validate z.z test /DEF
user 'test' has rw access to '/DEF'

It appears the authz file is correct and denies rcrespo access to /DEF.

I suspect the problem is a failure to enable authz at all--editing the
wrong config file, accessing the wrong repository, failed to restart
apache, something like that.

-- 
Philip

Re: Unable to checkout/add hidden files to repo

[Jon Grimes]

I had the same problem with both client version 1.5.1 that's installed on
the server and 1.6.12 that's on my laptop (ubuntu 11.10) .

This is an old server still running debian lenny, so it has not gotten many
updates lately. I don't really understand how this is just now coming up as
a problem. its possible that this has been happening for the last 2 years
and no one noticed, but its very unlikely. we run over 50 projects out of
this repo and all have hidden files like this in them.

Either way I'm glad i was able to figure it out.  it was about to be a long
day if i didn't. I was planning on moving our repo this year anyways to a
newer version of svn.  Now I think i'll make that a higher priority.

Thanks guys.

On Tue, Jan 31, 2012 at 8:33 AM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:

>
> On Jan 31, 2012, at 07:18, Jon Grimes wrote:
>
> > You guys were right.  I found the below line in my httpd.conf with a
> note saying i added it in April of 2010
> >
> > RedirectMatch 404 /\\..*(/.*|$)
> >
> > I don't understand how I'm just now having this problem though. Doesn't
> make any sense.
>
> You mentioned server version 1.5.1 but not client version. Subversion 1.7
> includes a new http implementation which is different from the old
> Subversion 1.6-and-earlier http implementation; I'm not sure if that
> requires a 1.7 server as well. If so, then there's still the serf vs neon
> difference; Subversion clients can use either, and they behave differently.
>
>
>

Re: tortoisesvn browser vs win repo browser

[Johan Corveleyn]

On Tue, Jan 31, 2012 at 2:47 PM, Ryan Schmidt
 wrote:
>
> On Jan 31, 2012, at 07:40, MM wrote:
>
>> I have a svn server configured with https.
>> I managed to browse the repo from a web browser (chrome) where it did ask me
>> for auth username and passwd.
>> However, using the exact same https://ipaddress as I used in the browser,
>> win repo browser of tortoisesvn fails saying "OPTIONS of https://ipaddress
>> could not connect to server.
>>
>> The tortoisesvn repo browser has worked from another IP area.
>
> When you browse a repository in a web browser, only GET requests get sent. 
> But when you use a real Subversion client, like TortoiseSVN, it uses other 
> WebDAV methods, including OPTIONS. What you're seeing could be the result of 
> a proxy that's not configured to pass WebDAV methods. Try disabling the use 
> of the proxy, or if that's not possible, talk to your proxy administrator 
> about supporting WebDAV methods.
>

I'm also thinking "proxy server". Your browser may have a proxy server
configured, but for use with any svn client (including TortoiseSVN),
you have to configure the proxy server in the client-side config file
(the file "servers" in %APPDATA%/Subversion). Or for TortoiseSVN: just
open the Settings, and go to "Network".

-- 
Johan

Re: svn status returns incorrect results on Windows 7

[Justin Johnson]

On Tue, Jan 31, 2012 at 2:47 AM, Johan Corveleyn  wrote:
> On Tue, Jan 31, 2012 at 3:35 AM, Justin Johnson
>  wrote:
>> On Sun, Jan 29, 2012 at 3:25 PM, Konstantin Kolinko
>>  wrote:
>>> 2012/1/27 Justin Johnson :
 Hi,

 I am running Subversion 1.7.2 64 bit installer from CollabNet on
 Windows 7.  The problem I'm experiencing can be seen in the output
 below.  In summary, svn status is returning incorrect results,
 sometimes not showing that something has been modified and sometimes
 not recognizing that I'm in a working copy.  This happens for me no
 matter how many times I recreate the working copy, and it happens if I
 store the working copy in C:\Users... as below or in C:\work.  I do
 not have the same problem when trying to reproduce the problem with
 svn 1.7.2 on Solaris.

 PS C:\Users\myuser\wc> svn st
 M       a\b\file.txt
 PS C:\Users\myuser\wc> cd a
 PS C:\Users\myuser\wc\a> svn st
 PS C:\Users\myuser\wc\a> cd b
 PS C:\Users\myuser\wc\a\b> svn st
 svn: warning: W155007: '.' is not a working copy

 Does anyone know why this is happening?  I searched for this problem
 and only found TortoiseSVN users complaining about it, and some
 suggestions to make sure the user has full control of the filesystem.
 I did this without resolution, but decided to post here since it is a
 Subversion issue (with Windows 7 perhaps) and not a TortoiseSVN issue.

>>>
>>> It can happen because of wrong capitalization in the path.
>>>
>>> Are "a" and "b" real names? Are you able to reproduce this with the
>>> Greek tree (repro-template.bat) [1]? Did you do the checkout with
>>> command-line client or with Tortoise?
>>>
>>>
>>> AFAIK, Tortoise 1.7.3+ does some additional work to normalize paths
>>> before passing them to Subversion library methods. (TSVN issue 156.
>>> There was notorious bug in that code - issue 169. Fixed in TSVN 1.7.4
>>> [2]).
>>>
>>> In my experience Windows command shell also does some normalization
>>> when I do "cd" command.
>>>
>>>
>>> [1] 
>>> http://subversion.apache.org/docs/community-guide/issues.html#reporting-bugs
>>> [2] http://code.google.com/p/tortoisesvn/issues/detail?id=156
>>> http://code.google.com/p/tortoisesvn/issues/detail?id=169
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>
>> Thank you so much for the reply.  It *does* have to do with
>> capitalization.  I never would have guessed that.  If I cd into
>> directories and always use the correct case, the commands work fine
>> every time.  If I cd into a path using the incorrect case, I of course
>> am able to cd but then svn doesn't return the correct results.
>>
>> Does anyone know if there are plans to fix this behavour in Subversion
>> as opposed to working around them in TortoiseSVN?
>
> It's not clear to me whether this is a problem in Subversion core (in
> which case TSVN now has a good workaround, but it should really be
> fixed in SVN), or TSVN calling the API in an incorrect way (in which
> case the only fix is in TSVN --- it could also still be a "bug" in the
> specs of the API of course).
>
> Maybe this is the same issue as the one reported here:
>
>    http://svn.haxx.se/dev/archive-2012-01/0247.shtml
>
> AFAIK, Bert Huijben was looking into that, but I'm not sure whether
> he's close to fixing it.
>

I get the problem using the svn that comes with the CollabNet
Subversion installer, so it is definitely a core svn problem and not
TortoiseSVN.

Re: Limited subdirectory access

[K F]

--- On Tue, 1/31/12, Andy Levy  wrote:

> From: Andy Levy 
> Subject: Re: Limited subdirectory access
> To: "K F" 
> Cc: "users@subversion.apache.org" , "MarkCooke" 
> 
> Date: Tuesday, January 31, 2012, 1:54 PM
> On Tue, Jan 31, 2012 at 08:22, K F
> 
> wrote:
> >
> >
> > --- On Tue, 1/31/12, Cooke, Mark 
> wrote:
> >
> >> From: Cooke, Mark 
> >> Subject: RE: Limited subdirectory access
> >> To: "K F" ,
> "users@subversion.apache.org"
> 
> >> Date: Tuesday, January 31, 2012, 9:25 AM
> >> > -Original Message-
> >> > From: K F [mailto:cmkfo...@yahoo.com]
> >>
> >> > Sent: 30 January 2012 20:40
> >> > To: users@subversion.apache.org
> >> > Subject: Limited subdirectory access
> >> >
> >> > We have repo ABC with 40+ subdirectories.
> Current svn
> >> > security allows developers rw permissions and
> qa read
> >> only to
> >> > ABC. We would like to have a subgroup of dev
> to have
> >> access
> >> > to subdirectory DEF (ABC/DEF). Is there a way
> of doing
> >> this,
> >> > or does the parent directory access take
> precedent?
> >> >
> >> > Thanks,
> >> > Rich
> >> >
> >>
> >> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html
> >>
> >> The most specific access takes precedent.  You
> would
> >> need to 'revoke' the normal developer's access to
> the subdir
> >> (if I understand you correctly) by assigning either
> 'r' or
> >> just nothing to their group...
> >>
> >> ~ mark c
> >>
> > I tried without anything and still no good
> >
> > [/DEF]
> > @dev =
> > @dev1 = rw
> >
> >
> > I have setup a test repo called sandbox with some
> subdirectories. Here is my authz file minus all the
> commented out lines:
> >
> > [aliases]
> >
> > [groups]
> > dev = rcrespo, test
> > dev1 = test
> > qa = qagroup
> 
> I can't explain why, and maybe it's been fixed in a later
> version, but
> I seem to recall having an issue with path-based
> authorization when
> the groups were defined with spaces. IOW, this:
> 
> dev = rcrespo, test
> 
> did not work properly but this:
> 
> dev = rcrespo,test
> 
> did.
> 
I removed the space and that didn't work. I'm open to trying anything that is 
suggested.

RE: Limited subdirectory access

[Bob Archer]

> I had already tried
> 
> [/DEF]
> @dev = r
> @dev1 = rw
> 
> and that did not work.

Did you step back further. 1st, svn is case sensitive, so is the path in 
question actually all upper case?

Even further back than that... did you try to just give all users read only 
access to root to ensure your path auth is working at all? Something like:

[/]
*=r

Maybe even turn of anon access to ensure your authentication is working as 
well. 

Add stuff one step at a time.

BOb


> 
> --- On Tue, 1/31/12, Thorsten Schöning  wrote:
> 
> > From: Thorsten Schöning 
> > Subject: Re: Limited subdirectory access
> > To: users@subversion.apache.org
> > Date: Tuesday, January 31, 2012, 8:04 AM Guten Tag K F, am Montag, 30.
> > Januar 2012 um 23:20 schrieben Sie:
> >
> > > [ABC:/DEF]
> > > @dev = r
> > > @dev1 = rw
> >
> > > Do I need the ABC in the front?
> >
> > If it's just one repository your configuring your authz file for,your
> > shouldn't need to specify ABC, so try without. If this doesn't work,
> > you really should provide the whole authz file with access rules for
> > all paths, groups, members and describe with which user you login and
> > can commit to which folder.
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> >
> > --
> > Thorsten Schöning       E-Mail:thorsten.schoen...@am-soft.de
> > AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
> >
> > Telefon.030-2 1001-310
> > Fax...05151-  9468- 88
> > Mobil..0178-8 9468- 04
> >
> > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG
> > Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
> >
> >

RE: tortoisesvn browser vs win repo browser

[MM]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: 31 January 2012 14:05
> To: MM
> Cc: users@subversion.apache.org; Ryan Schmidt
> Subject: Re: tortoisesvn browser vs win repo browser
> 
> On Tue, Jan 31, 2012 at 2:47 PM, Ryan Schmidt
>  wrote:
> >
> > On Jan 31, 2012, at 07:40, MM wrote:
> >
> >> I have a svn server configured with https.
> >> I managed to browse the repo from a web browser (chrome) where it
> did ask me
> >> for auth username and passwd.
> >> However, using the exact same https://ipaddress as I used in the
> browser,
> >> win repo browser of tortoisesvn fails saying "OPTIONS of
> https://ipaddress
> >> could not connect to server.
> >>
> >> The tortoisesvn repo browser has worked from another IP area.
> >
> > When you browse a repository in a web browser, only GET requests get
> sent. But when you use a real Subversion client, like TortoiseSVN, it
> uses other WebDAV methods, including OPTIONS. What you're seeing could
> be the result of a proxy that's not configured to pass WebDAV methods.
> Try disabling the use of the proxy, or if that's not possible, talk to
> your proxy administrator about supporting WebDAV methods.
> >
> 
> I'm also thinking "proxy server". Your browser may have a proxy server
> configured, but for use with any svn client (including TortoiseSVN),
> you have to configure the proxy server in the client-side config file
> (the file "servers" in %APPDATA%/Subversion). Or for TortoiseSVN: just
> open the Settings, and go to "Network".
> 
> --
> Johan

This worked, thanks very much,

MM

Re: Limited subdirectory access

[K F]

--- On Tue, 1/31/12, Philip Martin  wrote:

> From: Philip Martin 
> Subject: Re: Limited subdirectory access
> To: "K F" 
> Cc: "users@subversion.apache.org" , "MarkCooke" 
> 
> Date: Tuesday, January 31, 2012, 2:00 PM
> Stefan Sperling 
> writes:
> 
> > On Tue, Jan 31, 2012 at 05:22:15AM -0800, K F wrote:
> >> [groups]
> >> dev = rcrespo, test
> >> dev1 = test
> >> qa = qagroup
> >> 
> >> [/DEF]
> >> @dev = 
> >> @dev1 = rw
> >> 
> >> [/]
> >> @dev = rw
> >> @qa = r
> >> 
> >> I am still able to commit files in the DEF
> directory using the rcrespo login.
> >
> > Hmmm... I think you'll have to revoke the dev's group
> rw access on the root.
> > Then grant write permissions to subtrees individually.
> I suspect this is
> > because permissions for all path components are
> combined to form the final
> > set of permissions for a given full path.
> >
> > The book was wrong about this for a long time.
> > It claimed that permissions for earlier components of a
> path were
> > overridden by permissions for later components, which
> is incorrect.
> 
> I think that's misleading.  The error in the book
> involved a user
> matching multiple lines for a single location, like the user
> 'test'
> above.  When that happens the user gets the union of
> all the
> permissions, the book mistakenly claimed the first matching
> line was
> used.
> 
> Using the rules above in a file z.z:
> 
> $ tools/server-side/svnauthz-validate z.z rcrespo /ABC
> user 'rcrespo' has rw access to '/ABC'
> $ tools/server-side/svnauthz-validate z.z rcrespo /DEF
> user 'rcrespo' has no access to '/DEF'
> $ tools/server-side/svnauthz-validate z.z test /DEF
> user 'test' has rw access to '/DEF'
> 
> It appears the authz file is correct and denies rcrespo
> access to /DEF.
> 
> I suspect the problem is a failure to enable authz at
> all--editing the
> wrong config file, accessing the wrong repository, failed to
> restart
> apache, something like that.
> 
> -- 
> Philip
> 

I verified the file is correct. I tried committing with a login other than 
rcrespo or test and it does not allow the commit. Apache was restarted and I 
can still commit with rcrespo.

Here is what is in svnserve.conf in case something is set wrong there:
[general]
anon-access = none
auth-access = write
password-db = passwd
authz-db = authz

Re: Limited subdirectory access

[Philip Martin]

K F  writes:

> Apache was restarted and I can still commit with rcrespo.
>
> Here is what is in svnserve.conf in case something is set wrong there:

Apache doesn't use svnserve.conf.

-- 
Philip

RE: Limited subdirectory access

[K F]

I tried your suggestion of 

[/]
*=r

and I can still commit. So does that point to an error in svnserve.conf?

--- On Tue, 1/31/12, Bob Archer  wrote:

> From: Bob Archer 
> Subject: RE: Limited subdirectory access
> To: "K F" , "users@subversion.apache.org" 
> , "Thorsten Schöning" 
> Date: Tuesday, January 31, 2012, 2:46 PM
> > I had already tried
> > 
> > [/DEF]
> > @dev = r
> > @dev1 = rw
> > 
> > and that did not work.
> 
> Did you step back further. 1st, svn is case sensitive, so is
> the path in question actually all upper case?
> 
> Even further back than that... did you try to just give all
> users read only access to root to ensure your path auth is
> working at all? Something like:
> 
> [/]
> *=r
> 
> Maybe even turn of anon access to ensure your authentication
> is working as well. 
> 
> Add stuff one step at a time.
> 
> BOb
> 
> 
> > 
> > --- On Tue, 1/31/12, Thorsten Schöning 
> wrote:
> > 
> > > From: Thorsten Schöning 
> > > Subject: Re: Limited subdirectory access
> > > To: users@subversion.apache.org
> > > Date: Tuesday, January 31, 2012, 8:04 AM Guten Tag
> K F, am Montag, 30.
> > > Januar 2012 um 23:20 schrieben Sie:
> > >
> > > > [ABC:/DEF]
> > > > @dev = r
> > > > @dev1 = rw
> > >
> > > > Do I need the ABC in the front?
> > >
> > > If it's just one repository your configuring your
> authz file for,your
> > > shouldn't need to specify ABC, so try without. If
> this doesn't work,
> > > you really should provide the whole authz file
> with access rules for
> > > all paths, groups, members and describe with which
> user you login and
> > > can commit to which folder.
> > >
> > > Mit freundlichen Grüßen,
> > >
> > > Thorsten Schöning
> > >
> > > --
> > > Thorsten Schöning       E-Mail:thorsten.schoen...@am-soft.de
> > > AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
> > >
> > > Telefon.030-2 1001-310
> > > Fax...05151-  9468- 88
> > > Mobil..0178-8 9468- 04
> > >
> > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c,
> 31789 Hameln AG
> > > Hanover HRB 207 694 - Geschäftsführer: Andreas
> Muchow
> > >
> > >
>

RE: Limited subdirectory access

[Bob Archer]

> I tried your suggestion of
> 
> [/]
> *=r
> 
> and I can still commit. So does that point to an error in svnserve.conf?
> 

Yes, something is not configured properly. You are using the svn:// protocol to 
access your repository?

BOb


> --- On Tue, 1/31/12, Bob Archer  wrote:
> 
> > From: Bob Archer 
> > Subject: RE: Limited subdirectory access
> > To: "K F" , "users@subversion.apache.org"
> > , "Thorsten Schöning"
> > 
> > Date: Tuesday, January 31, 2012, 2:46 PM
> > > I had already tried
> > >
> > > [/DEF]
> > > @dev = r
> > > @dev1 = rw
> > >
> > > and that did not work.
> >
> > Did you step back further. 1st, svn is case sensitive, so is the path
> > in question actually all upper case?
> >
> > Even further back than that... did you try to just give all users read
> > only access to root to ensure your path auth is working at all?
> > Something like:
> >
> > [/]
> > *=r
> >
> > Maybe even turn of anon access to ensure your authentication is
> > working as well.
> >
> > Add stuff one step at a time.
> >
> > BOb
> >
> >
> > >
> > > --- On Tue, 1/31/12, Thorsten Schöning 
> > wrote:
> > >
> > > > From: Thorsten Schöning 
> > > > Subject: Re: Limited subdirectory access
> > > > To: users@subversion.apache.org
> > > > Date: Tuesday, January 31, 2012, 8:04 AM Guten Tag
> > K F, am Montag, 30.
> > > > Januar 2012 um 23:20 schrieben Sie:
> > > >
> > > > > [ABC:/DEF]
> > > > > @dev = r
> > > > > @dev1 = rw
> > > >
> > > > > Do I need the ABC in the front?
> > > >
> > > > If it's just one repository your configuring your
> > authz file for,your
> > > > shouldn't need to specify ABC, so try without. If
> > this doesn't work,
> > > > you really should provide the whole authz file
> > with access rules for
> > > > all paths, groups, members and describe with which
> > user you login and
> > > > can commit to which folder.
> > > >
> > > > Mit freundlichen Grüßen,
> > > >
> > > > Thorsten Schöning
> > > >
> > > > --
> > > > Thorsten Schöning       E-Mail:thorsten.schoen...@am-soft.de
> > > > AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
> > > >
> > > > Telefon.030-2 1001-310
> > > > Fax...05151-  9468- 88
> > > > Mobil..0178-8 9468- 04
> > > >
> > > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c,
> > 31789 Hameln AG
> > > > Hanover HRB 207 694 - Geschäftsführer: Andreas
> > Muchow
> > > >
> > > >
> >

RE: Limited subdirectory access

[K F]

--- On Tue, 1/31/12, Bob Archer  wrote:

> From: Bob Archer 
> Subject: RE: Limited subdirectory access
> To: "K F" , "users@subversion.apache.org" 
> , "Thorsten Schöning" 
> Date: Tuesday, January 31, 2012, 3:24 PM
> > I tried your suggestion of
> > 
> > [/]
> > *=r
> > 
> > and I can still commit. So does that point to an error
> in svnserve.conf?
> > 
> 
> Yes, something is not configured properly. You are using the
> svn:// protocol to access your repository?
> 
> BOb
> 
> 
> > --- On Tue, 1/31/12, Bob Archer 
> wrote:
> > 
> > > From: Bob Archer 
> > > Subject: RE: Limited subdirectory access
> > > To: "K F" ,
> "users@subversion.apache.org"
> > > ,
> "Thorsten Schöning"
> > > 
> > > Date: Tuesday, January 31, 2012, 2:46 PM
> > > > I had already tried
> > > >
> > > > [/DEF]
> > > > @dev = r
> > > > @dev1 = rw
> > > >
> > > > and that did not work.
> > >
> > > Did you step back further. 1st, svn is case
> sensitive, so is the path
> > > in question actually all upper case?
> > >
> > > Even further back than that... did you try to just
> give all users read
> > > only access to root to ensure your path auth is
> working at all?
> > > Something like:
> > >
> > > [/]
> > > *=r
> > >
> > > Maybe even turn of anon access to ensure your
> authentication is
> > > working as well.
> > >
> > > Add stuff one step at a time.
> > >
> > > BOb
> > >
> > >

If I understand the question, yes. For the dir in question it is

svn://subversion/svnrepo/sandbox/DEF

RE: Can relocate from a svnserve based server that was 'svn sync' to a new http based server

[Brent Webster]

There have been several replies telling me to use the 'svnadmin setuuid command 
and that worked great.

Thanks, Brent

-Original Message-
From: Lorenz [mailto:loren...@yahoo.com]
Sent: January-31-12 2:10 AM
To: users@subversion.apache.org
Subject: Re: Can relocate from a svnserve based server that was 'svn sync' to a 
new http based server

Brent Webster wrote:
>[...] I'm using svnsync to transfer the older "svn://" repositories to
>the new "http://"; repositories The problem that I'm having is [...]
>svn: E195009: The repository at
>'http://svnrepo2:18080/svn/admin/main/svnserver/bin' has  uuid 
>'65d03f8f-4f6b-4b7c-8505-7ddab04e9aed', but the WC has 
>'ad8b7147-7818-0410-a3fb-ed15fa4e4e0d'

every repository gets a unique ID (uuid) on creation.
But to be able to svn relocate, your new repo needs to have same uuid as the 
old one

See
http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.uuids
for more information.
--

Lorenz




This email, including any attachments, may contain confidential information, 
privileged material (including material protected by solicitor-client and/or 
other applicable privileges) or constitute non-public information under 
securities law(s). Any exploitation of the information contained in this email 
(including any attachments) by anyone other than the intended recipient is 
prohibited. If you have received this email in error, please reply to the 
sender and delete this information from your system as soon as reasonably 
practicable. Use, dissemination, distribution, reproduction, publication or any 
other exploitation of this email by unintended recipients is not authorized and 
may be unlawful.

RE: Limited subdirectory access

[Bob Archer]

> --- On Tue, 1/31/12, Bob Archer  wrote:
> 
> > From: Bob Archer 
> > Subject: RE: Limited subdirectory access
> > To: "K F" , "users@subversion.apache.org"
> > , "Thorsten Schöning"
> > 
> > Date: Tuesday, January 31, 2012, 3:24 PM
> > > I tried your suggestion of
> > >
> > > [/]
> > > *=r
> > >
> > > and I can still commit. So does that point to an error
> > in svnserve.conf?
> > >
> >
> > Yes, something is not configured properly. You are using the svn://
> > protocol to access your repository?
> >
> > BOb
> >
> >
> > > --- On Tue, 1/31/12, Bob Archer 
> > wrote:
> > >
> > > > From: Bob Archer 
> > > > Subject: RE: Limited subdirectory access
> > > > To: "K F" ,
> > "users@subversion.apache.org"
> > > > ,
> > "Thorsten Schöning"
> > > > 
> > > > Date: Tuesday, January 31, 2012, 2:46 PM
> > > > > I had already tried
> > > > >
> > > > > [/DEF]
> > > > > @dev = r
> > > > > @dev1 = rw
> > > > >
> > > > > and that did not work.
> > > >
> > > > Did you step back further. 1st, svn is case
> > sensitive, so is the path
> > > > in question actually all upper case?
> > > >
> > > > Even further back than that... did you try to just
> > give all users read
> > > > only access to root to ensure your path auth is
> > working at all?
> > > > Something like:
> > > >
> > > > [/]
> > > > *=r
> > > >
> > > > Maybe even turn of anon access to ensure your
> > authentication is
> > > > working as well.
> > > >
> > > > Add stuff one step at a time.
> > > >
> > > > BOb
> > > >
> > > >
> 
> If I understand the question, yes. For the dir in question it is
> 
> svn://subversion/svnrepo/sandbox/DEF

Ok... so you are using svnserve. For some reason your auth file isn't being 
read. What does your config file look like? 

BOb

RE: Limited subdirectory access

[Bob Archer]

> --- On Tue, 1/31/12, Bob Archer  wrote:
> 
> > From: Bob Archer 
> > Subject: RE: Limited subdirectory access
> > To: "K F" , "users@subversion.apache.org"
> > , "Thorsten Schöning"
> > 
> > Date: Tuesday, January 31, 2012, 3:24 PM
> > > I tried your suggestion of
> > >
> > > [/]
> > > *=r
> > >
> > > and I can still commit. So does that point to an error
> > in svnserve.conf?
> > >
> >
> > Yes, something is not configured properly. You are using the svn://
> > protocol to access your repository?
> >
> > BOb
> >
> >
> > > --- On Tue, 1/31/12, Bob Archer 
> > wrote:
> > >
> > > > From: Bob Archer 
> > > > Subject: RE: Limited subdirectory access
> > > > To: "K F" ,
> > "users@subversion.apache.org"
> > > > ,
> > "Thorsten Schöning"
> > > > 
> > > > Date: Tuesday, January 31, 2012, 2:46 PM
> > > > > I had already tried
> > > > >
> > > > > [/DEF]
> > > > > @dev = r
> > > > > @dev1 = rw
> > > > >
> > > > > and that did not work.
> > > >
> > > > Did you step back further. 1st, svn is case
> > sensitive, so is the path
> > > > in question actually all upper case?
> > > >
> > > > Even further back than that... did you try to just
> > give all users read
> > > > only access to root to ensure your path auth is
> > working at all?
> > > > Something like:
> > > >
> > > > [/]
> > > > *=r
> > > >
> > > > Maybe even turn of anon access to ensure your
> > authentication is
> > > > working as well.
> > > >
> > > > Add stuff one step at a time.
> > > >
> > > > BOb
> > > >
> > > >
> 
> If I understand the question, yes. For the dir in question it is
> 
> svn://subversion/svnrepo/sandbox/DEF

Are you restarting svnserver after you make config/auth file changes? Previous 
emails you talked about restarting apache.. but if you use the svn:// protocol 
you are NOT using Apache.

BOb

RE: Limited subdirectory access

[K F]

--- On Tue, 1/31/12, K F  wrote:

> From: K F 
> Subject: RE: Limited subdirectory access
> To: "users@subversion.apache.org" , "Thorsten 
> Schöning" , "Bob Archer" 
> Date: Tuesday, January 31, 2012, 3:29 PM
> 
> 
> --- On Tue, 1/31/12, Bob Archer 
> wrote:
> 
> > From: Bob Archer 
> > Subject: RE: Limited subdirectory access
> > To: "K F" ,
> "users@subversion.apache.org"
> ,
> "Thorsten Schöning" 
> > Date: Tuesday, January 31, 2012, 3:24 PM
> > > I tried your suggestion of
> > > 
> > > [/]
> > > *=r
> > > 
> > > and I can still commit. So does that point to an
> error
> > in svnserve.conf?
> > > 
> > 
> > Yes, something is not configured properly. You are
> using the
> > svn:// protocol to access your repository?
> > 
> > BOb
> > 
> > 
> > > --- On Tue, 1/31/12, Bob Archer 
> > wrote:
> > > 
> > > > From: Bob Archer 
> > > > Subject: RE: Limited subdirectory access
> > > > To: "K F" ,
> > "users@subversion.apache.org"
> > > > ,
> > "Thorsten Schöning"
> > > > 
> > > > Date: Tuesday, January 31, 2012, 2:46 PM
> > > > > I had already tried
> > > > >
> > > > > [/DEF]
> > > > > @dev = r
> > > > > @dev1 = rw
> > > > >
> > > > > and that did not work.
> > > >
> > > > Did you step back further. 1st, svn is case
> > sensitive, so is the path
> > > > in question actually all upper case?
> > > >
> > > > Even further back than that... did you try to
> just
> > give all users read
> > > > only access to root to ensure your path auth
> is
> > working at all?
> > > > Something like:
> > > >
> > > > [/]
> > > > *=r
> > > >
> > > > Maybe even turn of anon access to ensure
> your
> > authentication is
> > > > working as well.
> > > >
> > > > Add stuff one step at a time.
> > > >
> > > > BOb
> > > >
> > > >
> 
> If I understand the question, yes. For the dir in question
> it is
> 
> svn://subversion/svnrepo/sandbox/DEF
> 
I discovered what MY issue was. In the svnserve.conf file there were duplicate 
entries for 

anon-access = 
auth-access = 

Once I removed the duplicate entries and just had 

anon-access = none
auth-access = write

it started working as it should have. Thank you all for your patience and help. 
The whole thing was a learning process for me.

Rich

Re: Limited subdirectory access

[Daniel Shahaf]

Bob Archer wrote on Tue, Jan 31, 2012 at 10:50:45 -0500:
> Are you restarting svnserver after you make config/auth file changes?
> Previous emails you talked about restarting apache.. but if you use
> the svn:// protocol you are NOT using Apache.

Last I checked it wasn't necessary to restart svnserve to effect config
file changes.

(I don't recall whether that applies both to the config file and to
referenced files such as the authz file.)